This is where DevSecOps comes into play, so as to balance actions and decisions considering business priorities, aim to scientific decision making, provide consumable security services with APIs, measure with a business mindset, expand Red and Blue team exploitation scope, establish a 24-7 proactive monitoring process, share threat intelligence information, and define routines for continuous compliance.
The steps for a common DevSecOps workflow could be:
- A developer writes source code and a peer review is conducted on the new code.
- The source code is submitted into a repository with version control in place.
- The code is inspected using a Static Application Security Testing tool.
- If the code passes a business-driven defined bug bar, an environment is then created using an infrastructure-as-code tool.
- The software is deployed to the new test environment in which Dynamic Application Security Testing is conducted.
- If the application passes these tests, it is deployed to a production environment.
- This new production environment is continuously monitored to identify security threats to the system.
- Business-needs refinement causes the whole workflow to start again.
The DevSecOps Working Group of the Cloud Security Alliance (CSA) proposes six areas to successfully integrate Security processes into a business:
- Business goals should drive security requirements and they should be considered as the foundation of applications and be measured accordingly. The Security posture of the organization is everyone’s responsibility; in CSA’s terms, it is a Collective Responsibility. This requires a deep change in an organization’s mindset and culture regarding software security.
- Having an organization’s Security in good shape can only be achieved through Collaboration and Integration, which means that a successful implementation requires cooperation to take advantage of knowledge and resources in the Development, Operation, and Security fields and empowering everyone to inform potential anomalies as well.
- Every organization has a different software lifecycle in terms of structure and processes. There is no one-size-fits-all set of tools, and they need to find solutions that enable their own Pragmatic Implementation of Security that provides actionable insights to mitigate security risks.
- Risk-related requirements are difficult to translate into security requirements that can be easily measured over time, and compliance requirements are usually poorly translated to DevOps and product requirements. Identifying applicable controls and translating them into appropriate software measures and identifying where these controls can be automated and measured to improve the quality of risk mitigation will make it possible to Bridge Compliance and Development.
- Some issues preventing software development practices from implementing an idea to secure deployment quickly and at a minimum cost are: poor coding, testing, deployment and patching practices. Well implemented Security Automation practices improve efficiency and reduce rework. All processes should be devised with the intention to be automated, and those that cannot, even partially, should be considered for elimination.
- Without actionable metrics, progress cannot be measured and failures cannot be detected on time. Some of the most critical metrics to monitor in a DevSecOps environment are: Deployment frequency, Vulnerability patch time, Automated code testing percentage, and amount of Automated tests per application. The results during software development as well as post-delivery must be Measured, Monitored, Reported and Acted Upon continuously by the right people at the right time.
By considering these areas in your business you will be able, not only to reduce implementation time, but also to establish the basis for a robust Security process.
