You’re familiar with the typical development workflow: You have the security, development, and operations teams and you understand how they function on a day-to-day basis. Traditionally, you would have each team working in their areas of expertise. It makes sense.
The status quo has its weaknesses, however. This approach compartmentalizes teams and create communication and visibility gaps. DevSecOps is a philosophy and practice that is meant to bridge this gap between development, security, and operations.
The emphasis on speed across the industry, prioritizing the quick release of a Minimum Viable Product (MVP), often results in security and safety taking a backseat during decision-making. While practices and processes are great, managers, teams, and stakeholders need to focus on a cultural shift that synergizes security with development and operations. DevOps is focused on fast, repeatable releases and keeping development and operations closely working together.
In the Software Development Lifecycle, or SDLC, “shifting left” is the practice of helping developers find coding, configuration, integration, and deployment errors as early in the process as possible.
Learn more: 3 Reasons Your Cloud Offering Needs to Shift Left on Compliance
DevSecOps aims to “shift security” practices further left in the SDLC process, making security a primary focus within the DevOps culture and within organizational processes—catching and remediating security issues early becomes just as important as getting an MVP out the door.
In many organizations, security is an afterthought and tends to be segregated from other teams. This mindset can be costly and time-consuming, as retroactively addressing findings and weaknesses takes additional development time and release cycles. Integrating security into the process builds a faster feedback loop, reduces cost and operational overhead, and improves security posture.
One key concept in this space is Infrastructure as Code (IaC): IaC allows us to define our infrastructure using code, typically in declarative languages, which essentially acts as a blueprint for our workloads. Once we have this blueprint or template, we can standardize security configurations across our environment.
In the context of IaC, we often use a CI/CD pipeline, where we can define stages to verify configurations, fail deployments if they don’t meet certain criteria, rollback changes if needed, and so on.
Learn more: Security Best Practices for Dev Environments
A simple, yet practical, example in the context of SDLC and CI/CD is a build pipeline. Let’s say we have a stage in our pipeline that is building Docker images and uploading the artifacts to a registry. We could use a tool such as Docker Scout to scan these images for known common vulnerabilities and exposures (CVEs). If an image does not meet our defined requirements, it would fail during the build stage of the pipeline. Consequently, the Docker image would not be published to our registry and thus, no deployments would trigger. This “shift left” enables us to fail fast, fail early, and fail often as well. We have effectively shifted security earlier in this process, enabling us to address vulnerabilities sooner and avoid using potentially vulnerable images in production.
A high-level example of “shifting left” even further than your CI/CD pipeline is implementing pre-commit hooks that run scripts or code before a commit is pushed to a remote repository, providing immediate feedback to developers. Another example is leveraging IDE plugins to assist with linting, formatting, and detecting potential issues in real time within the development environment.
Another example of security and even compliance within our pipeline is a great tool called `cdk-nag`. This tool allows us to call specific rules directly within our CDK package that can check for various best practices or requirements based on the following rule packs:
And during synthesis of your CDK Stack, you get immediate feedback regarding best practices for the resources that will be creating within AWS:
Furthermore, if this were to be integrated into your CDK pipeline, you get a multitude of options on how you want your pipeline to proceed based on the output. You could simply fail your synthesis step, add any suppression rules (if necessary), notify team members, etc. Developers can also review the controls output directly in their terminal (as shown in the example above) and make any necessary changes within their CDK package. This helps ensure that any resources created via CDK are meeting the requirements of the rule pack before they’re even pushed to source or deployed into environments.
Similarly, if you’re using Terraform instead of CDK in your environment, there’s a tool called terraform-compliance that provides feedback much like cdk-nag. Once you have a Terraform plan or state file, you can run terraform-compliance against it. This can be done locally in your terminal or integrated into your CI/CD pipeline.
The importance of tools like cdk-nag or terraform-compliance can’t be overstated, especially when implemented in CI/CD. By focusing on compliance requirements during development, before deploying resources, we’re taking a proactive approach to compliance. Essentially, we’re creating “compliance-as-code.” While this may initially add to development time, it ultimately saves time and prevents headaches by addressing potential misconfigurations before they reach production environments.
As we progress through the CI/CD process, we can incorporate more advanced security measures such as Software Composition Analysis (SCA), Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), or even Interactive Application Security Testing (IAST), which combines aspects of SAST and DAST, into our build and test stages. These measures allow us to implement security gates or checks based on specific outputs and desired actions. Furthermore, post-deployment security measures like penetration testing and Red/Blue/Purple team exercises are crucial for comprehensive security.
DevSecOps remains a somewhat fluid concept, encompassing various philosophies and lessons from development, operations, and security; there’s no one-size-fits-all solution for every organization. The key is to prioritize security as a fundamental aspect of your process and to automate and integrate security measures wherever possible. Begin with what’s feasible for your team, whether it’s a simple build stage check, IDE plugins, or implementing SAST during testing. Start there, iterate, and gradually integrate security throughout your SDLC over time.
38North Security can help you integrate DevSecOps into your software development lifecycle. Get in touch with a cybersecurity expert today.
About the Author
