Application Security in Agile delivery – Integrating Security in SDLC and DevOps

Methodologies for development of applications have evolved in the last decade drastically especially after the mainstreaming of Cloud services. With providers offering IAAS, PAAS (Not covering SAAS in this case), companies can easily deploy their codes instantly by utilizing these services. With the exponential increase in application-based services, Application Security has also evolved. Penetration testing or VA at the end of release cycle is no more possible in agile methodology as it adds delays and becomes a bottleneck for companies and clients. This bottleneck can be eliminated by integrating Security in conventional SDLC framework in conjecture with DevOps.

Security in SDLC:

SDLC (Software Development Life Cycle) is software development framework that lists and explains the process and stages of any application development. It divides the whole cycle into multiple phases:

Traditional SDLC doesn’t address the security aspects and related risks in the cycle thus what needs to be followed instead of SDLC is Secure – Software development life cycle (S-SDLC). The idea of which is to embed Security in each of SDLC phases to reduce the time of delivery and reduce the risks associated with code changes. 

During the Analysis phase, business owners define functional requirements. These functional requirements are then translated into user stories by business analysts and passed on to the development team as the features that needs to be developed. Security team needs to do threat modeling against these functional requirements and shall give their security requirements against these user stories to help developers do secure development. These Security requirements are also translated into test cases for later testing. The idea of giving security requirements is not to object/contradict functional requirements mostly but to guide the developers on how to securely develop these features. Example of this can be:

In the Design phase, architects design the flow and the technical architecture of the whole solution. That solution shall be validated by Security architects to make sure there are no loopholes. Moreover this phase also help finalize the Security designs and requirements for monitoring in operations (SOC Requirements, Use cases etc.)

Next up, in the Build phase when the developers start developing the features, security team needs to keep on providing guidance and run workshops as per security requirements defined for the developers.

Testing phase requires user acceptance testing which is mostly for functional people and testers to perform. But adding a parallel stream of penetration testing and source code review against security requirements would mean that the application security team has verified the implementation of the requirements they had given before. One argument here is that penetration testing or source code review in parallel to functional UAT might add delays in the delivery but in my experience the number of vulnerabilities would reduce as the process becomes more mature. Developers, if follow the security guidelines and develop the requirements properly; which if are covering most of the threats/risks mean that there will be lesser vulnerabilities in that build. There is always a conflict between the developers and the security team on the severity of vulnerabilities, the best way around it is to formalize a process on how each vulnerability’s severity will be reported with the delivery team. I will cover this in another article in detail.

During the Deployment phase, security team verifies the Network/App/WAF etc. configurations, roles and access matrices, deployment checks, and some test cases which are data related. Last, Evaluation stage requires constant monitoring or operations of the application where other technical controls are quite useful. These controls and their requirements were defined in design phase as well.

Since SDLC is a cycle that repeats itself for every development (regardless of the scope), S-SDLC also is a cycle where the involvement of Security team shall be embedded in each phase during the whole cycle. One important point here to make is the governance around these things that companies struggle to establish. By following this process, Security team becomes a stakeholder in the whole development process and shall be involved in each phase and also shall provide their feedback during the change management meeting to provide approval for Production deployment.

Security in DevOps

The idea for bringing DevOps is to solve the problem of how to more rapidly deliver higher-quality, products to customers. DevOps is a process of bringing people of different skills (developers, middleware team, DBAs, infra team and Security team) together to achieve a common goal. Its more towards bringing the culture than having tools (which people generally focus on). But for the sake of this article we will focus the technological part of it ??.

One more thing that the industry has not agreed or has not standardized is three variants of DevOps with Security. You would find people using DevSecOps, SecDevOps and DevOpsSec interchangeably where instead all three terms have different meaning and scope for Security team. You can check what the difference is but for this article I will cover SecDevOps because it to me is more practical and has more value than other two approaches.

SecDevOps means security activities happening before development and operations start. People thinking about Security before other activities has the best intentions and they will be able to plan the development and operations in a secure way.

Merging S-SDLC in DevOps - SecDevOps:

Merging S-SDLC practices in DevOps means automating certain parts of DevOps by embedding Security in it. Now talking about the practice, the design and analysis phase will remain the same as they are in any normal S-SDLC process but the inputs of Security requirements can be added as test cases for automation. It also involves having Security automation within the dev and within your CI/CD (continuous integration/continuous delivery) pipelines. Developers shall be validating the code using tools at the build phase while the static and dynamic code analysis and testing shall be automated through the CI/CD pipeline. Similarly, the deployment which are automated in any DevOps environment can have Security configurations, IAM rules and Security checks automated.

Conclusion and Caveats:

As someone who is a fan of manual penetration testing compared to automated VA reports, Embedding Security in DevOps does not mean that penetration testing can be bypassed or can be relied on automated tools. What it actually means is that the scope of penetration testing is reduced considerably by automating certain test cases through DAST and SAST (Dynamic Application Security Testing and Static Application Security testing) tools. Another caveat in using this process is the maturity of these Security tools. These tools work on certain heuristics and flows which often gives false positives thus the reliance on these reports cannot be much. Also, the vulnerabilities that are business flow related cannot be verified through these products. Thus, embedding Security into the process doesn’t necessarily mean that it will not add delays, but it means to find a right balance to deliver Securer application within the DevOps cycle by enabling SecDevOps. This process also ensures that the business has the required assurity to go operational and all risks are managed properly.

All-in-all, Embedding Security in agile methodologies using S-SDLC adds a lot of value to achieve the desired results of DevOps and can reduce considerable time in delivering projects regardless of the size of the project. Security shall never be considered as roadblock but as an enabler and making it part of the process takes away the delays.