What's Inside
Learn how to apply DevSecOps automation effectively in any organization using the "4Is process" and industry-standard security controls.
DevSecOps Automation: The 4I Process
Get Started With Drata
Contents
DevSecOps automation is about more than automating security configuration. It requires a modern perspective on governance and a desire for continuous, monitored compliance with regulatory standards.
This article explores the process and practical steps for leveraging DevSecOps automation to improve your organization’s security and compliance posture.
How to Apply DevSecOps Automation to your Organization
The “4Is process” describes an ideal approach to DevSecOps automation, encompassing four activities: inventorying, identifying, implementing, and iterating. The table below summarizes these actions, described in more detail in the following sections.
“4Is” Process step | Description |
Inventory your environment, starting with broad categories and working down to more specific categories and then to assets | Start broadly by looking at the categories into which your assets fall. A common way to categorize assets is by location (e.g., deployment location or code storage location). |
Identify the highest-priority asset category using a prioritization matrix | A prioritization matrix (such as the one in this article or a bespoke matrix) helps you identify your highest-priority asset categories. |
Identify security controls you can apply to a given category using industry-standard best practices | You can obtain relevant security controls from compliance requirements and lists such as the OWASP DevSecOps Automation Matrix and the Cloud Controls Matrix. |
Implement a solution—ideally, one that scales with your organization and offers a central place to view your current compliance status | Build out a solution, remembering that it is OK to start small as long as you keep improving. Also, remember that ideal solutions will scale with your organization to save time and effort and improve security posture. |
Iterate through this cycle, applying the feedback you learn along the way | Achieving and maintaining a robust security posture isn’t a single step; It’s a constant process of iteration and improvement. Regularly consider the weaknesses in your security and compliance posture. Look for ways to shift security compliance left to get quicker feedback and engage developers/engineers. |
Use the “4Is Process” to Guide Your Work
To structure how to apply DevSecOps automation to your organization, we recommend using something like the “4Is Process,” which consists of these steps:
Inventory: Take an inventory of your environments and their assets.
Identify: Identify the top priorities and security controls for these priorities.
Implement: Put into place a solution that applies and monitors the security controls.
Iterate: Iterate through the process, applying feedback to either re-inventory your environment (if it’s very dynamic) or identify the next-highest priority.
The process looks something like this:
From the Iterate step, you can loop back to either Inventory or Identify, depending on how long it took to complete the process and how likely your environment was to have substantially changed in the meantime.
Inventory
Before applying automation, it is important to know what (and how, where, why, etc.) to automate. To that end, start by taking inventory of your environments to know where security is lacking or could be automated to reduce manual workload.
A common mistake is taking an inventory of all individual software components. This can quickly become tedious and unproductive because you may have hundreds or thousands of individual software components. Instead, start by categorizing your ecosystem at a higher level to get traction more quickly. An excellent place to start is by listing all the locations where your code and applications live.
For example, the fictitious Acme Corporation is a large e-commerce company. They might start by listing something like this:
Where software is stored:
GitHub
Where software is deployed:
AWS
On-premises servers
They may then break this down further, as shown in the table below:
Category | Location | Components |
Software Storage | GitHub | “Acme R&D” project |
“Acme Platform” project | ||
Software Deployment | AWS | Elastic BeanStalk |
Lambda Functions | ||
On-Premises Servers | File Servers | |
Kubernetes Clusters |
The team at Acme Corp. can continue to expand these sub-points until getting to the individual software components. Working from the general to the specific is a great method for inventorying your organization’s assets.
Identify
Once you’ve inventoried your assets, it’s time to identify the top priority and the appropriate security controls for that priority. To determine the top priority, you can use a prioritization matrix that scores the different assets or asset locations on criteria such as:
Risk of compromise
Impact if compromised
Current effort to maintain compliance and security posture
Intuitive sense of importance
There are different ways to score each criterion. Here, we are just using a simple 1-3 scale where 1 is “low” and 3 is “high,” but you can refine this. You can also consider many different criteria; this list is just illustrative, not exhaustive.
For Acme Corp., a prioritization matrix might look something like this:
Scoring asset categories using a prioritization matrix like this will give you a sense of your top priority.
Once you’ve identified your top priority, you must determine what security controls apply to that asset or asset location.
There are several ways to do this, but here are two good starting points:
Create a list of requirements for any compliance standards you want to meet. There are various places to find these; here’s an example from Drata, which has a list of required controls for each compliance standard:
The OWASP DevSecOps Automation Matrix gives you a sense of what needs to be considered for a given environment (e.g., a Kubernetes cluster).
Implement
Once you’ve identified your top priority and its security controls, it’s time to take action!
The action will be specific to the system you are working on, but for illustration, let’s walk through how to implement a CI/CD script that runs a vulnerability scan on a GitHub repository using GitHub Actions.
Admittedly, this is an elementary example, but this is how many organizations start, and it will illustrate some good practices as well as some areas for improvement as your DevSecOps maturity scales.
For this example, we’ll create a GitHub Action that uses the safety Python package to check a Python codebase for vulnerabilities.
To get started:
Create a .yml file in your repo’s .github/workflows/ directory.
Create a requirements.txt file if you don’t already have one. If you want to see safety detect something, you add the following to your requirements.txt for testing.
With this setup, every push to the repo will run safety and fail if safety finds any vulnerabilities. You could also trigger this action on a schedule to ensure more frequent executions. Note that the safety check command has been replaced with safety scan, which requires a free account. Run safety scan locally for more details, and use safety scan if you use this script in a real-world application.
This solution has several benefits, including being free and easy to implement and offering clear and reliable feedback. However, it also has some drawbacks:
No centralized reporting/status view across multiple repositories
Difficult to create reports for auditors
Does not alert outside of GitHub (although you could add this as another GitHub action step).
Does not scale well. What happens if you apply this approach to hundreds of repositories and then discover you need to configure the scan differently? Because there is no central monitoring system, you must make this change everywhere this script is used. There are ways to do this programmatically, but it requires a bit of overhead.
It’s ok to start small when implementing DevSecOps automation, but be mindful of an approach's limitations. Questions like these are helpful when considering any automation:
How well does this approach scale?
How easy would it be to change?
How up-to-date are the status checks?
How accessible is reporting on the system?
Iterate
Imagine that you’ve taken the previous steps to improve your organization's security posture. Now it’s time to create feedback loops to help you improve your processes and save time.
Generally speaking, you should be able to answer questions about the cost and benefit of your automation. Here are a few of the many ways to measure this:
How much time do we spend maintaining a given automation over a given time period?
How often does this automation catch something?
How severe are the issues this automation catches?
How long does it take the automation to run?
How much time do we estimate this automation saves? This is likely a function of two other questions:
How often does this automation run?
How much time would it take someone to run this manually?
These are a good starting point for identifying the effectiveness of automation.
In the context of the previous example about a GitHub workflow to find vulnerabilities, you could do the following:
Track the amount of time you spend maintaining that GitHub Action.
Send a brief survey to developers who use the automation to gauge how helpful they find it.
Add a step to the GitHub Action that increments a count every time the scan finds a vulnerability
These give you various data points to refine and improve your solution.
How DevSecOps Automation Can Help Your Business
You can read more on the benefits of compliance automation here, but we want to share a few thoughts to support your efforts to improve your organization's security posture.
There are a lot of benefits you can highlight. When done correctly, DevSecOps automation does all of the following:
Reduces manual effort
Reduces the risk and rate of manual errors
Improves your security team’s ability to scale with a growing organization
Improves visibility and reporting (for internal teams and auditors)
Regardless of which benefits of DevSecOps automation you highlight, be sure to communicate the benefits in terms of business value so stakeholders appreciate the value of automating security and avoiding the cost of non-compliance.
Additionally, spend time getting buy-in from all stakeholders. If your automation sometimes requires developers to be involved, ensure they understand the value of their involvement in the process.
If your automation will affect a team’s roadmap, work with the relevant project managers to find a good time to add it. You can also streamline the onboarding process as much as possible. A little documentation goes a long way.
