Application Security has become a significant issue for the software industry. As applications grow in codebase size and complexity, so do the surface areas for software security vulnerabilities and exploits. DevSecOps is the missing link between security and DevOps in many organizations. In DevSecOps, prioritizing secure SDLC collaboration and managed deliverables can help organizations address application security vulnerabilities.
DevSecOps is an approach that aims to deliver secure software using manual and automated security assessments and deployment workflows to help developers build secure applications effectively. DevSecOps follows the 'Security By Design' policy, guidelines, and best practices to implement security-infused software development, testing, and release.
Implementing a successful DevSecOps in your organization depends on IT/Product security policies that act as a driver to push 'Security By Design' guidelines across the product and project development lifecycle. Without IT/Product security policies, people and processes may not collaborate to complete DevSecOps deliverables.
A matured DevSecOps framework contains several phases in a continuous integration and development(CI/CD) pipeline. The product team should satisfy agreed-upon security deliverables at each stage before moving to the next step.
DevOps to DevSecOps
DevSecOps enforces security policies, compliances, and best practices that the product team should implement in each phase of the traditional DevOps: Plan, Design, Develop, Test, Release, and Maintain.
Plan
Your organization's security policies and compliances are the key drivers for all DevSecOps activities. The journey towards DevSecOps begins with the planning phase, where you establish scope, strategies, roadmaps, requirements, the definition of done, risk assessment templates, collaboration tools(Jira and Confluence), and infrastructure as code(IaC) tools.
Map all finalized security & privacy requirements inside the risk assessment document. Ensure to remediate essential security requirements gaps and update residual risks in the risk assessment report.
Key deliverables in the Planning phase are;
a) Security Requirement Specifications (SRS)
b) Definition of Done
c) Risk Assessment report
Design
Review the product architecture documents and generate the security architecture review report. Use the security architecture to build a threat model and security design. These activities help you to identify threats early in the DevOps, and a security architecture review is your first milestone toward DevSecOps.
Security design implements the architecture, and security architects and development engineers review the security architecture and build threat models using the tools such as Microsoft Threat Modeling and IriusRisk. Threat models often identify threats and potential attack surface areas in the architecture and establish countermeasures to mitigate the threats early in the design phase.
Document the outcome of the threat modeling in the risk assessment report, and mark all genuine threat issues as security risks. Initiate a design change request for open security risks and resolve the risk.
Key deliverables in the Design phase are;
a) Security Architecture and Design Review report
b) Threat Model
c) Risk Assessment report
Develop
Start development activities with secure coding standards and best practices, configuration and deployment standards Infrastructure-as-Code(IaC), Configuration-as-Code (CaC), and Monitoring-as-Code(MaC) in place.
Infrastructure-as-Code manages and provisions the development infrastructure using management tools such as Terraform, Chef, Puppet, and AWS Cloud Formation. Configuration-as-code contains configuration files and establishes the controls for configuring applications, processes, and operating systems in the development infrastructure. Monitoring-as-Code enables DevOps to utilize a framework to monitor the application evolution for minor or major version changes and releases.
Ensure 3rd Party Components required for application development adheres to the internal vendor management process, IT security policies, and license agreements.
During application development, implement Static Application Security Testing (SAST) to identify and mitigate vulnerabilities in the code base. Too many false positives and false negatives? Follow manual code review to knock off false positives and determine the security issues that SAST tools fail to recognize.
Update your risk assessment to capture the identified and mitigated risks during the development phase of DevSecOps. Apply risk mitigations on all open security issues to arrive at residual risks.
Key deliverables in the Development phase are;
a) Third-party Component Analysis report
b) SAST report
c) Risk Assessment report
Test
Offensive security activities inside DevSecOps ensure issues not identified in the development phase are found and mitigated in the testing phase. Execute Dynamic Application Security Testing(DAST) scans to uncover Web Application and API vulnerabilities.
Vulnerability Scanning on infrastructure identifies vulnerabilities in Cloud Configuration, Microservices, Containers, Kubernetes, Servers, Third-party components, and Networks.
Penetration testing aid in discovering zero-day attacks, and exploiting the vulnerabilities helps determine the correct severity and risk rating. Invite your penetration testing teams to execute the tests, and identify hidden issues and dev teams to mitigate the problems.
Fuzzing uncovers security issues overlooked in SAST, DAST, Vulnerability Scanning, and Penetration Testing. Submit your applications and protocols to black-box(Intruder, ffuf, etc.), grey-box (Peach, WinAFL), and white-box (AFL) fuzzers. Fuzzing applications and protocols often catch severe security issues such as memory corruption bugs and software instabilities.
It is time to update the risk assessment report to capture the identified and mitigated risks during the testing phase of DevSecOps. Apply risk mitigations on all open security issues to arrive at residual risks.
Key deliverables in the Testing phase are;
a) DAST report
b) Vulnerability Scanning report
c) Penetration testing report
d) Fuzzing report
e) Risk Assessment report
Release
In the release phase, your security architect shall confirm that every deliverable, as per the security Definition of Done, is complete and signed off. Review the risk assessment report to validate high-severity risks mitigation status.
Key deliverables in the Release phase are;
a) Review the Definition of Done
b) Risk Assessment report
Maintain
In the maintenance phase, monitor for security events. Release and apply software patches to mitigate security issues. Perform periodic vulnerability assessments to identify security issues and update your risk assessment report to track the issues reported.
Key deliverables in the Maintain phase are;
a) Security Patches
b) Monitor Security Events
c) Periodic Vulnerability Assessment reports
c) Risk Assessment report
Conclusion
From our DevSecOps framework above, notice that the Risk Assessment report is a living document that includes every security decision you have made during the DevOps. Use the open risks reported as input to create new security requirements for upcoming upgrades.
The Risk Assessment-based DevSecOps helps you to attain maturity in your existing DevSecOps process by eliminating redundant/outdated security operations, improvising the dev and security team collaboration, and adding the latest and best security practices.
Register for instructor-led online courses today!
Check out our free programs!
Contact us with your custom pen testing needs at: info@darkrelay.com or WhatsApp.