Secure coding practices: A busy dev's guide to bulletproof app security

 

1. Speak the board's language. Discuss vulnerabilities in terms of risk to the business, such as potential financial loss, reputational damage, legal implications, and operational disruptions.

2. Use real-world examples. Cite recent high-profile cyber attacks and their impact on businesses. Show how vulnerabilities could similarly affect your organization.

3. Provide a cost-benefit analysis. Show how secure coding tools can save money in the long run by preventing costly breaches. You can also focus on the value of reducing the time and resources spent on fixing future security issues. 

4. Emphasize compliance and regulatory standards. Explain how secure coding practices help comply with industry standards and regulations, reducing the risk of legal penalties.

5. Keep it simple. Use layman’s terms to explain vulnerabilities. Avoid overly technical language that may not resonate with non-technical leaders.

6. Provide an implementation plan or roadmap. Present a clear, step-by-step plan for integrating secure coding practices into the development lifecycle. Extra points if you can offer a realistic timeline for implementation and expected milestones to track progress.

 

Secure development lifecycle frameworks

Knowing what steps to take for stronger security throughout all stages of the software development lifecycle can be confusing. 

Fortunately, a number of secure software development standards and frameworks can help your team get started. 

An example of a public standard is NIST’s Secure Software Development Framework (SSDF). Another good framework is the Microsoft Security Development Lifecycle (SDL).

These standards follow the principle of “security by design.” Security issues are considered at all stages. Starting with gathering requirements and the subsequent design. 

If you work in the US, especially in the public sector, you will probably follow the NIST standard. In other countries, or where there is no obligation to follow NIST, the Microsoft SDL offers a comprehensive approach to the secure development lifecycle.

Do you have to implement all aspects of these frameworks? 

Of course not. But understanding them and applying relevant elements to your development project is a good start. These elements can be broken down as follows: 

Security requirements

Developers understand the principles of gathering the functional requirements for a software application. However, they may not be aware of the need to detail the security requirements at the same time. 

This will include considerations of the basic CIAAA model: confidentiality, integrity, availability, authentication, and authorization. The other security principles that are key include the principle of least privilege and defense in depth. 

Threat modeling

This process allows the developer to identify and assess security threats and vulnerabilities, consequent risks, and potential mitigations. 

Developers should understand the context of where and how their software will be used to fully understand the threats: medical software vs software that gives exercise tips for example.

Manage the security risk of third-party components

All software developed today will use third-party libraries, frameworks, and services. When these are incorporated into a product, they come with their own security vulnerabilities and risks. 

Knowing what packages, libraries, and components the application is using is an essential first step. 

But it is not always obvious since a component you use in development may rely on another, that relies on another; so the potential number of components used may be large. 

Tools such as GitHub’s Dependabot can help with this by automatically notifying you when an insecure package or component is being used.   

4 Secure coding practice fundamentals 

Adopting a set of secure coding guidelines is good practice. There are a number of these guidelines available including the OWASP Developer Guide. It provides a checklist for developing web applications against the top vulnerabilities detailed by OWASP each year. 

Multiple vendors will also include secure coding guidelines for their languages and frameworks. Examples of this include Microsoft’s .NET and Oracle’s Java SE guidelines.

1. Code reviews

Reviewing code for security before it is incorporated into the main repository is key. The review should be conducted with a security developer or peer before it is accepted. 

The purpose of a code review is to verify that the security and other coding guidelines have been followed and to identify any vulnerabilities. All identified issues should be corrected before the code is accepted.

💡Tip: Static Analysis Security Testing (SAST) automates the process of discovering potential security vulnerabilities in code. You can find a comprehensive list of SAST tools on the OWASP website.

2. Dynamic security testing

Testing of the compiled and running version of the application for security issues should be part of the automated build/test part of the Continuous Integration/Continuous Deployment (CI/CD) process. 

This looks for issues with memory corruption, privilege issues, and the potential for attacks like SQL injection and Cross-Site Scripting, amongst others.  

3. Penetration testing

In addition to vulnerability scans, penetration tests can be carried out by internal or external security staff (or even trained developers) to probe for code security flaws. 

If possible, developers should familiarize themselves with the penetration testing and vulnerability hunting process—it will give them practical insight on how to avoid costly vulnerabilities when coding. 

Exploiting a vulnerability to get remote code execution for example, or executing a SQL injection attack to exfiltrate the contents of a database, grants developers and other team members first-hand experience of the consequences of not respecting application security.

4. Bug bounty programs

Using bug bounties is a good way of getting the security community to try and find vulnerabilities in a released, or soon-to-be-released, product. 

In an official bug bounty program, the scope can be controlled, and organizations can be used to interface and screen vulnerability reports.

There’s a chance that vulnerabilities might be disclosed by a third party, and it is always a good idea to review and respond to these disclosures. 

It is beyond the scope of this article to investigate the details of this process, but the key here is to not ignore the person bringing the vulnerability to you. The worst case is that the vulnerability is disclosed without a fix being ready for clients and users.

Develop your team’s secure software development skills 

Embedding security as a core aspect of the development process, and not an afterthought, has never been more important. 

It enables your team to build software that is not only robust and secure, but also delivers a seamless user experience.

Becoming a secure developer starts with the acknowledgment that security should be central in all parts of the software development lifecycle, starting with the principle of security by design. 

Whatever your level of experience, Hack The Box is a good way of either gaining skills in secure development or updating them through the numerous labs and training modules that highlight software vulnerabilities.