DevSecOps Reference Architecture
When approaching a complex DevSecOps implementation, it is often useful to consider a Reference Architecture as a starting point. As illustrated in Figure 1, the automation activities can be broken up into three major areas: Continuous Integration (CI), Continuous Deployment (CD) and Continuous Compliance (CC). Each of these areas encompasses a separate target for DevSecOps implementation. For example, a team can automate the build, test, and security scan aspects of CI without fully implementing automated deployment. However, to realize the full benefit of the architecture, it is necessary to have all areas built out and functioning as a unit. This includes proper integration across the selected pipeline of tools.
There are many tools available in the marketplace to enable a DevSecOps automated delivery. For example, many automated pipelines are managed by CloudBees(TM) Jenkins workflow automation. Source control is often fulfilled by a variant of ‘git’, such as BitBucket, GitLab, or GitHub. Automated code scanning can be accomplished with a variety of open-source and commercial products, such as SonarQube, Veracode, Sonatype-Nexus IQ, or Blackduck. Xebialabs (provider of deployment tools) offers a very nice summary page for most of the currently available tooling.
Figure 1. DevSecOps automated pipeline reference architecture
Beyond tools, it is important to consider how the development, operations, and security processes will integrate with the automated delivery pipeline. For example, release coordination is critically important to the delivery of products into production environments. An inefficient release review and approval process can derail the most efficient DevSecOps pipeline. In the reference architecture, this is represented under the Governance aspect along with operational monitoring and deployment practices.
Continuous Integration (CI)
Continuous Integration automates the repetitive aspects of system building, packaging, unit testing, and security scanning. This allows development teams to focus energy on fulfilling feature requests rather than on the mechanics of system building. Moreover, this approach addresses the dreaded “it works on my laptop” problem where code changes break when combined with contributions from other team members. Building a full system on every approved submission (e.g. merge to the Development or Master code line) allows for verification of unit test coverage, early detection of security policy violations, integration failures, and collisions with other developer’s code.
Source Control
Source control is a key aspect of CI automation. The selection of the proper SCM tool facilitates integration with the pipeline workflow such that key events can trigger pipeline activities. For example, a product such as BitBucket can integrate directly with Jenkins to initiate the CI pipeline build process upon specific events (such as a code merge or a pull request approval). By selectively choosing these code-level events, the CI pipeline can be leveraged to dramatically speed development.
Build management
Many, if not most, software systems must be compiled, linked, or otherwise converted from raw code into an executable product. These steps typically include the resolution of dependencies, such as third-party components or libraries. The end result of the build phase is a versioned “deployable unit” as the basis of automated deployment.
Automated Unit Test and Test-Driven Development
After the system builds, it is common in DevSecOps pipelines to perform some level of automated unit test. Teams who leverage TTD (test-driven development)are best able to leverage automated unit testing, given the unit tests are the first code artifacts created for any given feature.
Security and Compliance Assurance
Automation of secure code verification is a core best practice for DevSecOps automation. There are three automated scans performed for each CI build: secure code practices, third-party component use, and application penetration testing. The first two scans are often considered “static” code scans as they refer to the code base before compilation. The third test looks at the end product (such as a web-application) and verifies resistance against common attacks (e.g. OWASP Top Ten vulnerabilities).
Continuous Deployment (CD)
In contrast to CI, Continuous Deployment manages the consistent delivery of deployable units into target environments. This element of DevSecOps automation manages system parameters, connection details, encryption, secrets, and other ‘run-time’ requirements. Deployment tooling simplifies the management of these values.
Repository Implementation
All deployments should be made from a verified deployable unit. This is to ensure that each promotion to subsequent environments (e.g. Dev to Test to Production) always leverages the exact same build products. The use of a repository is therefore critical to ensuring versioning of these deployable units. Moreover, repositories can manage libraries, components, and other build-time dependencies.
Infrastructure as Code
A goal of DevSecOps automation is to reduce or eliminate repetitive tasks from the delivery pipeline. The target environment for a particular system build should always be in a predictable state. This avoids time-consuming deployment problems when one environment configuration drifts from another. By encoding the expected system, secondary installed components, and network configuration this uniformity can be enforced at deploy-time.
Configuration Management
Along with establishing and maintaining a target environment configuration, the associated system parameters and connection information must be maintained. As noted above, this is the purpose of configuration and secret management tools. Decoupling environment configuration information from the deployable unit greatly reduces the likelihood of a deployment error breaking the automation.
Continuous Compliance (CC) and Governance
The final DevSecOps reference architecture section covers compliance and governance. For many, compliance with regulatory, industry, or customer demands requires that the organization expend valuable time verifying and approving adherence to security policy. To the greatest extent possible, this compliance audit function should be automated.
Automated Compliance Audit
It is important to verify the configuration state of any target environment to ensure the consistency of servers, networks, and data access points. Likewise, the security hardening of operating systems, network policy/restrictions, firewall/load balancer configuration, and other system security aspects should be verified before system deployment. This is particularly necessary for production deployment, but should not be neglected for lower environments.
Release Coordination
As discussed in my post on Release Coordination, a poor system release process can significantly degrade the advantages gained by automating CI and CD operations. Expected delivery performance is assured with an agile process joined to DevSecOps automation.
Environment Monitoring and Control
Support for operations and on-going system monitoring is the final aspect of the DevSecOps reference architecture. This will enable the operations team to better respond to problems before they occur.
Conclusion
DevSecOps implementation is a non-trivial event. Multiple integrated tools, processes, and policies must be aligned. Leveraging a consistent reference architecture will ensure that all aspects of the automation work closely together. In this post, I have detailed one such architecture.
