With this article, we hope to highlight good practices in software and application development. In short, what you should take into consideration to be able to develop secure applications and software, however and wherever they will be distributed. We will be predominantly talking about development practices, not DevOps, but we may revisit DevOps in future.
Put people first
It is important that developers are security conscious and to build that awareness, offering training and development is imperative. Developers who understand secure coding practices are developers who will knowingly write more secure code and produce, in turn, more secure applications and software. Good development hygiene practices, such as writing clean, maintainable code reduces the complexity of your application, increases its maintainability and supports security by design.
Allowing developers time for personal development, as well as arranging external and peer training in secure development practices, helps build confidence and an understanding of how to avoid inadvertently introducing security vulnerabilities into code. There are a number of freely available resources, which can support learning, including the OWASP Top Ten Web Application Security Risks and the Mitre Common Weakness Enumeration (CWE) database.
Know your context
Even before writing a line of code, you must understand where you are going. We’re not advocating drawn-out waterfall charts that stretch years into the future; however you should know who the audience is likely to be, where and how the software or application will be hosted and consumed and what sort of threats your application is likely to be exposed to. All of this taken together helps you to make intelligent security decisions. Depending on how much of the stack you control, you can decide where is best to implement the layers of security necessary to protect applications and software today.
Expectations and legislation around the privacy and security of data are evolving, so you need to be thinking about how you will protect the data that you hold, both at rest and in transit. Do you need to employ techniques such as encryption, anonymisation and pseudonymisation? This should also be considered within the context of the types of threats your software or application will face. For a typical web application, if you’re going to be making available an API or using web forms, you should be considering how you will protect against Cross Site Request Forgery (CSRF), what data sanitisation you should be employing and how best to mitigate SQL injection attacks.
Thinking about the typical Agile example of building a car by iterating on a skateboard, we’re not advocating building ABS brakes into your skateboard. Rather, your skateboarder should have knee pads and a helmet and, as your application becomes more complex, you must keep in mind that ABS brakes will eventually be required, because knee pads, although they provide enough protection now, are not going to adequately protect the driver once they get behind the wheel.
Have a process
Having a secure development process or lifecycle is a key part of building secure software. There are existing models for secure development, which can be taken and applied to your organisation. One of the best known is Microsoft’s Security Development Lifecycle, but there are others. Applying a layer of governance, in the form of a formalised, gated development process ensures that high-quality code is being produced and released. As we see across organisations, security initiatives that are implemented in isolation, and without consideration for the culture of the organisation, are doomed to failure as staff inevitably find ways to work around the controls, therefore to successfully implement a secure development lifecycle, governance teams and engineering teams need a seat at the table and ownership of the initiative.
Review and test your code
Implementing code review and automated code scanning, or static analysis, are important measures that can identify common errors that can lead to security vulnerabilities, well before the code is released.
When putting in place a secure development process, it is easy to believe that automation can cure all problems; however, though automation of security checks and controls helps, security decisions are rarely black and white and there must be a level of discretion and human input. Techniques such as pair programming and peer review are important tools in the security arsenal and help organisations develop higher quality, secure code quicker, while spreading security knowledge throughout the development team. One caveat to note is that it is important that security-minded developers are paired with developers that are less knowledgeable about secure development practices, to enable this knowledge transfer and that this is done alongside personal development and organised training to ensure high-quality security practices are being modelled.
Prior to releasing code and within your live environment, it is important to perform penetration testing to validate the robustness and security of your application. Organisations should use a third-party penetration testing provider to ensure that testing is conducted impartially by skilled, knowledgeable and competent professionals. In the UK, using a CREST accredited member company provides that assurance.
Use caution when integrating third-party components
Using third-party libraries, frameworks and other dependencies is easy; however it is also easy to assume that code provided by vendors and the publicly available code on NuGet, PyPI, Packagist or the NPM Registry is secure and well written, unfortunately, that is not always the case. Developers and organisations should exercise caution when integrating third party code, as there have been a number of high-profile vulnerabilities in commonly used libraries. To protect against introducing vulnerabilities through third-party components, you should audit and rigorously test the third-party code you are using. Applying the good practices above will go a long way to protecting your application, your customers’ data and your organisation from the risks associated with third-party components. Should a breach happen, it makes no difference to your users whether the code was written in house or by a third party, the reputation that is damaged is that of your organisation.
Measuring and improving development security maturity
Models exist to help you to plot your own development security maturity, including giving organisations the ability to compare their own maturity against other organisations within their vertical. Probably the best known of these models is the Building Security In Maturity Model, currently at version 10. Though these models can be helpful, the Building Security In Maturity Model only shows activities that are common, believing that commonly observed security practices are useful, rather than giving a maturity score based on the complexity and value of the activities.
It is worth remembering that any model based on observation is only as good as the organisations being observed. It may be that some new and emerging practices do not make their way into the model as they are not being observed in the organisations involved in the development of the Building Security In Maturity Model. Conversely, there may be commonly held security practices that offer little security benefit.
To conclude, secure development is everyone’s concern. As an organisation, you need to make sure that developers’ security knowledge is up-to-date and potentially have someone championing new and emerging threats and technologies, so that you stay at the forefront of secure development practice. Writing secure code, performing testing and being mindful of the third-party components that you integrate go a long way to reducing vulnerabilities and protecting your company’s reputation. This article was written in collaboration with my colleague Jacques du Toit. For a personalised view of how your business can benefit from building a secure development culture, please reach out to either of us via LinkedIn.