Cyber Academy Blog Series: DevSecOps - Securing Value at the Pace of Continuous Delivery

Integrating security into DevOps is a widespread and significant challenge. Misconfigured and vulnerable products cause data loss, financial penalties, and reputational damage across industries.

Product teams following DevOps are deploying applications at speed, automating operational tasks and continuously changing code. Security, if introduced incorrectly can slow down and inhibit the value of DevOps and will be perceived as a blocker, fostering a negative security culture.

Effective DevSecOps organisations all have the same thing in common, they recognise and prioritise DevOps values and infuse security activities into their work via tooling and process. ‘shifting left’ on the software lifecycle offers profound benefit in understanding threats in design and weaknesses in code during build stages. The ability to embed security controls at design and build stages can then be measured as security metrics to report and prioritise risk.

Shifting Process Left – removing checklists and non-functional requirements (NFR)

Whilst checklists and non-functional requirements (NFR) are measurable and easy to establish for security teams, its implementation is often ineffective. The lack of relevance to a particular product on a checklist/NFR makes it challenging for product teams to implement as development tasks, stories or epics.

By fusing security reviews early into the solution design of a product, architects and developers can work with security teams to identify exploitable technical features and business logic flaws. This practice is known as threat modelling.

Threat modelling involves ceremonies between security and solution architects to understand and document exploitable design flaws. It reviews technical controls and business logic against the ability to maliciously manipulate a feature. This means security should be exploring threat tactics (e.g. initial access) to exploit a product. Cyber attackers would use the initial access tactic example to exploit insecure cloud configuration, vulnerable input fields, accessing publicly exposed vulnerable containers, or accessing public code repositories. This brings to surface the conversation of security to a more meaningful and material level with DevOps and product stakeholders. At the same time the method to address the threat will become more relevant in comparison a generic checklist/NFR, which can either be too long, verbose and irrelevant in scope and often lacks the meaning of ‘why’ developers need to apply a security control. The collaborative conversation of resolving threat model findings can then be agreed either by implementing a new product security feature, recycling existing security controls, changing design of products, procuring new solutions or creating process workarounds.

Threat models allow controls to be agreed that are operationally effective and benefit both parties – resulting in security controls addressing respective threat vectors whilst at the same time complimenting the principles of DevOps.

Figure 1: Mapping threats to DevOps principles

Shifting tooling left – scanning at the right place and time

The reliance to test applications and infrastructure post-build, at deployment, has been a common cause in slow-release cadence, leading to additional security work causing delay and in-turn frustration. Products deemed functionally ‘ready’ to go-live are typically security tested and reveal exploitable security flaws that require fixing through patches, code changes or re-design. This creates the perception of security being expensive in time and money. Shift security left is a notion that can benefit all stakeholders. Whilst we can keep post-build testing processes in place (e.g. penetration testing), teams can introduce tools to perform security scans during coding or once it’s been committed to a source code repository.

For organisations developing their own source code, Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools are effective at build to provide visibility to developers of vulnerabilities in static code – before it’s compiled - and identify dependency risks in third-party and open-source libraries. Scanning early and often – shifting security left – means tooling like SAST and SCA are pointed to source code repositories. Developers can run scans within their existing sprints to observe vulnerabilities and address low-hanging fruit (quick fixes) within their existing sprint/task, which typically includes syntax changes, bug fixes and library updates, in turn reducing the mean time to remediate vulnerabilities and can even reduce the volume of penetration test findings.

Whilst DevSecOps tooling like SAST and SCA can be introduced, the absence of shifting security left can make the management of security work ineffective. Organisations still get it wrong by following traditional counter-productive methods and point these tools (SAST and SCA) to a production code base or trigger scans in pipelines during a deployment. This results in vulnerabilities being accepted into live environments, subsequently introducing risk where developers have to plan future work to fix security vulnerabilities. Whilst DevSecOps tooling like SAST and SCA can be introduced, the absence of shifting security left can make the management of security work ineffective.

Figure 2: Security scanning at build

Shifting right to provide a security assurance

Whilst shifting left yields many benefits, the ‘shift right’ to pre and post deployment can provide ample opportunities to demonstrate security assurance and better present risk. Shifting security right is the addressing of security at pre / post deployment – essentially the security work before and after a product is deployed to production.

Using post-compilation scanning for both your application (e.g. Dynamic Application Security Testing and Penetration testing) and cloud infrastructure (e.g. Cloud Security Posture Management) provides continuous security posture reviews of vulnerabilities and weaknesses that are exploitable. A product exploit like injection, cross site scripting, or insecure and vulnerable cloud designs represents palpable project risk that should be reported and addressed with longer term strategies that can demonstrate a burndown of risk. Reporting only these types of vulnerabilities can be powerful and leveraged by CISOs to map project risks (e.g. insecure AWS s3 bucket) to key business risks (e.g. data leakage) to provide insight to Business Leaders on cyber risk, cost, performance and resilience.

For organisations already achieving this, more can be done. Security metrics, engineered efficiently, can provide further insight to measure security posture and help cost prioritisation. Visibility through metrics can in some cases be easy to achieve, however high performing organisations may choose to focus on metrics that better educate effort, spending and dependency risk, otherwise known as observability.

Trending security risks and vulnerabilities: the volumetrics of vulnerabilities and risks per product/project depicted in trends to measure burndown or an increase in security issues, which educate security performance.

Measuring sprint volume and release cadence: the development effort and goals over a period of time as well as future planned work, which can contextualise security trends or identify patterns where security effort can be prioritised.

Measuring security control volume: the frequency for the use of a respective security controls - tools or process – to help avoid wasted effort and cost incurred by recreating or reprocuring solutions that already exist. This also helps measure the success and effectiveness of a respective control and is the starting point to mapping these controls to DevOps principles.

Tracking defence in depth average: the average volume of security controls applied to address each threat or risk - often difficult to measure – this educates teams on the acceptability of remediation activities and can help further improve threat modelling exercises.

Visibility, culture, tools and collaboration

For each facet of success, think about how shifting security left and right can improve the outcome of security work:

• Agility: Security scanning code early and often allows teams to move faster with easier access to vulnerabilities during build. Security implemented effectively can increase release cadence by reducing security findings before deployment.
• Culture: Responsibility and accountability of security doesn’t just belong to security teams but also product teams, created through collaborative threat modelling and empowering product teams with access to security tools scanning their codebase.
• Collaboration: Security design reviewing with developers and architects who know their products best, prove to be most effective in reverse engineering product features and managing the prioritisation of security remediation work overtime.
• Tools: Scanning for vulnerabilities and weaknesses in both static code and runtime provides the ability to automate cumbersome task that are otherwise expensive to perform manually. It’s also the foundation for continuous improvement as teams can begin to focus more time and effort for fixing security issues.
• Visibility: Understanding the value and output of security work through data and metrics can help demonstrate security posture. It’s the foundation for measuring security performance, known as observability, to determine tool, method and process effectiveness.

Beyond the recommendations for shifting security left and right; do something now – refine later.

Reach out to the team to learn more about DevSecOps and securing value.