Where and how to put Sec in DevOps?

Like usability or performance, security can be defined as a property or quality of a software product. Security issues are bugs and, therefore, generally all measures that improve code quality (e.g. coding guidelines and best practices) and reduce the number of bugs also have a positive impact on security. Typically, not all developers in a project can be security experts (but some should be), everyone on the team needs to have a basic understanding about trust boundaries, threat modeling, attack trees and awareness of the most common security risks [2,3] and how these are managed. For security to become part of the backlog, miss-use cases by anti-personas and corresponding negative testing should be added to the normal “happy path” requirements and testing by using, for example, the STRIDE-model [4]. This results in security being included in the “definition of done”.
Agile teams are self-organised and autonomous and should not be centrally controlled, not even by the security team. However, existing corporate security teams can put enablers in place to help the agile teams to produce secure software – these might include education about and easy access to (i.e. self-service and automation-ready) security tools, patterns, configurations, hardening templates as well as checklists.

Reliable, consistent and repeatable generation of deployable software whenever there’s a committed change in the source code is the goal of the automated build and deployment pipeline. However, the privileges and power of the deployment pipeline make it a very attractive target for an attacker: insertion of malicious code or deliberate misconfigurations that are automatically deployed and pushed to all servers can wreak havoc. Protection of the build pipeline including artifact repos, continuous integration and delivery servers, configuration management servers and all build, deploy and release tools is essential. The classic security measures like hardening, access control and privilege management (for both humans and machines (tokens, API keys)) as well as audit log generation should be applied to protect from unauthorized access and tampering with code and tools.

Vulnerabilities can stem both from design flaws in the system as well as implementation errors (bugs) and can result in data, systems or people being misused, exposed or harmed in some other way. Code reviews and extensive testing at multiple layers are the most common measures to prevent vulnerabilities. While we’d like to automate as much as possible in DevOps with automated code scanning, the human forms of pair programming and peer reviews (“pull requests”) are still of extreme importance in DevOps. The automated reviews and security tests need be lightweight, practical and fast and should be integrated into the overall test pyramid and deployment process. Typically, white-box / black-box and static / dynamic scans are combined and applied at different stages in the process.

Static security testing includes analysers and linters in the Integrated Development Environment (IDE), compiler warnings and dedicated code vulnerability scanners (SAST) that are able to detect insecure coding practices (missing input validation or potential buffer overflows), hard coded credentials or potentially other sensitive data.

The classification and sensitivity of customer, business and log data, and hence the necessary security and privacy measures, are highly application- and use-case specific and need to be thoroughly addressed as part of the SSDF. These measures are implemented with methods that are based on keys or other secrets that need to be protected similarly to application secrets like passwords, API tokens, configurations or certificates. None of these should be stored directly in the code base which usually is accessible by a larger audience than intended for the secrets. Keys and secrets should be easy to rotate and access or change should be logged in a tamper-proof way. Dedicated key management systems and vault solutions have evolved to cater the needs of a DevOps-environment.

Although DevOps is basically orthogonal to anything cloud-related, the flexibility, agility, standardization and automation capabilities of the cloud, make DevOps and the cloud good bedfellows. This means that security in SecDevOps most often also implies cloud security [5]. From a DevOps perspective the setup and configuration of all cloud assets (compute, storage and network) is code, which improves security and compliance by means of repeatability, consistency and reliability.  Although in the cloud “everything is virtualized”, cloud-native developers shouldn’t forget that for software-defined infrastructure and networking most of the classic concepts such as network segmentation, DMZ or traffic filtering are still important and necessary.