Time to Production: DevSecOps – the deployment pipeline for secure software

Many companies today align their software development with the DevOps model. But saving time alone is not enough, security aspects must be included from the very beginning – keyword: DevSecOps.

The second article in my series “Time to Production” has shown the optimization potential that system operation and administration can achieve through close cooperation with development, QA and product managers as well as consistent use of tools. However, it is too short-sighted to use a deployment pipeline to make new code available to users in real time: the pipeline should also deliver a secure application in a secure and monitored system environment.

Series of articles “Time to Production”:

Similar to DevOps, DevSecOps is a composition of terms – development, security and operations – and should be understood as a model, not a role. In this context it does not refer to the developer who has access to the production systems and is also responsible for security. The areas of responsibility of system administrators, developers, testers, product managers and security experts (e.g. information security officers, ISMS officers, risk managers, data protection officers or auditors) will always require a degree of separation that is reasonable for the size of the company. Similar to DevOps, DevSecOps also pursues the ideal of constant close cooperation between these areas (not their merging) and mutual learning from best practices and technologies.

Security as a quality criterion

DevSecOps is nothing else than the practical implementation of a holistic IT security concept, as I have already described in my article “Four Core Components of Higher IT Security“. In principle, this is about security being understood as a quality feature by all parties involved in the software lifecycle, but the foundation for quality is always laid at the beginning.

Safe development is only the first step

The recipe for developing high quality software is well known and proven: It requires developers with a good sense of quality and teams with collective responsibility for overall quality. Furthermore, stable and proven process models, base systems, tools and components as well as a solution to make needed knowledge available to developers at the right time. Project-related training courses on best and bad practices have proven to be very useful. With regard to security, developers should regularly put themselves in the role of an attacker and think about what can attack their software. A tool for automated code analysis such as SonarQube, which can interrupt the process and report back very promptly if the code violates certain rules, also helps with continuous integration. With regard to the development of secure software, it is very advantageous that rules such as OWASP (Open Web Application Security Project) or CWE (Common Weakness Enumeration) are taken into account.

Interdisciplinary learning and collaboration

Raising awareness on security issues should extend beyond the development phase to all parties involved in the software lifecycle. As already noted in the DevOps model, the cross-departmental lessons are particularly useful: Developers, quality managers, product managers and system administrators can learn many practices from each other which they can use beneficially in their own area. For example, the developer should understand how a production environment is protected against external attacks and where its weak points are. The system administrator, in turn, should know where the weak points in the “inner life” of an application lie in order to better secure it on the system side, so to speak “from the outside”.

Integration of security checks into the continuous delivery

If a deployment pipeline is operated, which makes code changes made by developers available to users in near real time in a runtime environment, the process usually contains several test stages which, in the event of an error, can lead to the code being discarded and a message being automatically returned to the developer. The security quality feature should be handled accordingly. Automated code analyses with, as mentioned above, security-relevant sets of rules are possible, as well as automated penetration tests at application level (before deployment) and at system level (after deployment in a runtime environment). These tests can also be configured in a way that the pipeline does not provide a new application release in the event of serious security violations, but instead issues a corresponding message and ideally provides immediate assistance in eliminating the vulnerabilities.

The DevOps model is able to significantly reduce the time to production: New requirements are ideally implemented immediately and are available to the user in almost real time. Once an organization has implemented this model, it can use DevSecOps for a relatively small additional outlay in order to differentiate itself from the competition: secure systems, sensitive employees in all areas, a high frequency of security tests and a short lead time for improvements.

What is your experience with IT security in conjunction with automated software deployment?

Picture: Shutterstock

One thought to “Time to Production: DevSecOps – the deployment pipeline for secure software”

Leave a reply

Your mail address will not be published. Required fields are marked with *.