Software has become an integral part of almost every business and organization today, regardless of whether developing software is their core product or not. From rideshare companies to logistics firms, these companies rely heavily on software to drive their operations and provide value to their clients. But what are the fundamental parts of software development and how does application security fit into that development life cycle?
It starts with a client’s request being turned into a development feature or enhancement. These requests are then transformed into use cases and requirements that are pushed to the development team for development. The development team and its leadership will determine where to slot the work so that it can be made available in an upcoming release. The designers and architects will make decisions on how the requirements will be implemented through technology choices. Once the design and architecture choices are made, the development begins, and the feature is integrated into a branch. It is then moved into a pre-production environment where testing occurs.
This testing environment may include system tests, integration tests, and other types of testing that help determine whether the feature is meeting the client’s needs and performing as expected. Once the feature passes through the testing and activities, it is released to the client for use. In fact, some of these testing environments may allow client access so that they can have an early view of the feature and provide feedback. This feature will be integrated as part of a larger application or a set of applications. Once in production and in the hands of the clients, the operational team will support this feature through client and technical support. If the organization has a strong lifecycle management process the feature and application will eventually be decommissioned in favor of a new release.
What about ensuring that this feature or application has security well integrated to keep it free from software security issues and reduce the risk to the organization of a breach? This is what we call “application security”, and it will be integrated as an augment to the software development process. It will ensure that developers have the knowledge and capabilities available to them to write secure code from the start. Furthermore, they will have the assurance that their code is free from vulnerabilities through testing.
The process of integrating application security will start at the design phase, where the team will perform threat modeling and risk assessments to highlight any risks to the design decisions. This will often lead to the creation of security requirements that dictate how the software should behave in a secure way. During development secure code reviews will be performed, often by a security resource, to review the developed code for security issues. This can be augmented by leveraging the existing threat model and risk assessments to know what code changes have impacts on the overall risk of the application.
While many of these processes are manual and time consuming, the organization can leverage automation and tools to assist as well. They can integrate tools into their development environment in order to provide the developer with the ability to check their code early in the process. Ideally while they are writing it. This allows them to make corrections early and, more importantly, cost effectively. These same tools, or variations of them, are available to teams during the CICD (continuous integration and continuous delivery) to mitigate and remediate security issues before they become a vulnerability within the production environment. These scanning tools can scan the code as it sits in the repository or scan the running application once it’s deployed to a testing environment. Mature organizations will use this as an opportunity to block releases that pose a high risk to the organization. For example, the organization may take the position that no critical or high findings can proceed to production. They may even take the position that no found vulnerabilities will be allowed in the production environment at all. While this may be extreme, it’s obviously a better security practice. However, it will slow the pace of releasing features to clients. This is where the organization needs to take a balanced approach to their risk management and look to run-time protection tools to provide some level of protection against identified vulnerabilities.
Every organization is different in how they develop software and how they deliver it to the client. However, the fundamental parts of application security remain the same. Simply put: deliver software with the assurance that the risk to the organization is minimal. I’ll dive into these details more in the coming months, but by following these steps and using available tools, organizations can ensure that their applications are secure and free from vulnerabilities while still providing value to their clients.
If you’d like to learn more about this, check out The Application Security Program Handbook on Amazon for more information.