Security Think Tank: Three steps to a solid DevSecOps strategy

This article was first published in Computer Weekly.

Yet cutting time and cost up front can often lead to expensive rework or significant risks downstream. Retrofitting security and belated patching is more complicated, less resilient and makes the solution harder to use and maintain. This approach also flies in the face of the latest software development thinking, where automation is king and bolting on security hinders time to market.

So, how can we help developers build in security from the outset? It should start with implementing a secure-by-design approach to drive good security into products and services from their inception. This can reduce through life cost, but it does require practical and tangible changes in tooling and ways of working.

Then there are a specific number of actions development and security teams can take together to reduce risk and improve security.

Develop using agile incorporating business and security ambitions

One of the easiest ways to de-risk software development is to develop it iteratively, pivoting as needed and tackling changes in a granular fashion using agile to capture business requirements and play them back for confirmation regularly. However, traditional approaches to security break this model and slow it down, giving security a bad reputation.

A simpler approach is to define the security outcomes and embed the security engineering within the DevSecOps squad, making it an equal partner in development. Security then becomes part of the software development.

With the easy availability of security code for re-use and sufficient control frameworks, this moves security engineering from a gatekeeping role to one which adds value and quickly bolsters application security.

Build an ecosystem of tooling and automation for DevSecOps

To implement DevSecOps, the ecosystem in which it thrives needs time to be built and be continually improved. The secure software development lifecycle has security inbuilt into each stage of the pipeline and requires three key principles to be implemented:

Security automation: The pipelines should automatically carry out basic security checking of code, as it is written in the integrated development environment, when it is tested and built, and finally when its deployed aligning with standard continuous integration/continuous development (CI/CD) principles.

There are a plethora of static application security testing/dynamic application security testing (SAST/DAST) tools that can be used, noting that they are not all equally good. The data from these tools allows automated pipeline decisions, but also allows ecosystem evolution.

Many cloud platforms provide native guardrails, and in more advanced pipelines using standards such as OpenSCAP, will allow compliance checking with security standards and enforcement.

Security testing is still seen as something “special” that cannot be done as part of normal testing in software development. However, if it is baked in, it will be done transparently, and explicit security enforcing functions will have automated test scripts, like any other code.

Vulnerability and supply chain checking: Vulnerability checking of the code and the third-party libraries and verification of the provenance is essential. Ecosystem tooling should immediately report vulnerabilities such as Log4J without false positives.

This requires time to get right and fine tune, but having the correct image scanners and software composition analysis tools are prerequisites. Additionally, have signed attestations that security tooling has passed and the code’s integrity can be trusted should be acquired before code is deployed.

Continuous developer interaction: Providing developers with meaningful security information as the software is developed is vital for fast fixes. The pipeline should fail when any of the security checks fail and alert the developers immediately to the problem. Security linting, the process of running a program that will analyse code for potential errors, is a very useful tool for getting it right from the start.

All this work underlines that security flaws are just a different type of bug and developers should take at least the same care and pride in delivering code that is free from security bugs as they do in eliminating bugs that affect function.

Embed a security culture across development teams

A culture needs to be set from the top which recognises that security is a quality issue with severe brand and financial ramifications if not undertaken properly. Personal accountability and, conversely, incentivisation of teams based on product security will help drive the right behaviours and culture.

That should be underpinned by practical action to build secure-by-design thinking into the development processes and into the way they train and reward developers. This will help to build the relationship between security and development, and create an effective DevSecOps ecosystem.