6 ways to apply automation in devsecops

The goal of devsecops is to integrate security throughout the software development life cycle. To do this, the security team can’t focus on just the most obvious software development vulnerabilities or just the processes that are the easiest to secure. Instead, every step of the end-to-end development life cycle needs to be understood and properly secured. Automation can help.

Software development processes are complex. In most organizations, multiple distributed development teams follow different devops processes and use different devops tools. Further, applications are often deployed to multiple clouds or in multiple geographies. Automation is the only way to efficiently ensure security given this permutation of processes and the huge volume of data that businesses manage today.

When done right, automation reduces the possibility of human error, of something important being missed through carelessness or complexity. It ensures consistency of workflows, configurations, and security rules across diverse teams and over time. It allows developers to focus on coding instead of manually checking for security issues, a task that both reduces productivity and essentially guarantees that errors will be made. Automation also ensures consistent decision-making when vulnerabilities are detected.

In short, automation should serve as a foundational principle for approaching every security challenge. In this article, I’ll examine six critical areas of the software development life cycle, discuss what can be automated, and suggest some best practices for doing so.

Code security

Many data breaches and successful hacks against companies result from code vulnerabilities. Attackers can often infer usernames and passwords from code, as well as the location (IP address) of sensitive data, making it easy for them to enter a system, move around in it, and access private customer information. If a company has hundreds of developers on distributed teams writing code for microservices, the risk of introducing vulnerabilities into code is extremely high.

Manual checking of code at scale is highly impractical. Even the use of a scanning tool (or multiple tools) has its limitations. For example, these tools come with pre-configurations for “standard” development environments, but these configurations may be inadequate for a specific environment, lacking the context to determine what constitutes a vulnerability and what actions to take when a vulnerability is identified.

Properly configuring scanning tools is an important first step. However, automating scanning whenever code is checked in or changed is essential to ensuring vulnerabilities are fixed before any further action on the code is possible.

Image security

Once the code is approved, the next step is creating an image or build that can be tested and deployed. As with code security, tools help with creating an image, but once again, these tools by themselves may not ensure best practices.

An image is a combination of several pieces of code and often includes third-party or open source libraries, which are prebuilt and therefore not subject to the code scanning tools. As a result, it’s essential to know what components make up the image — the number of developers, the third-party libraries, etc. This is known as the software bill of materials, or SBOM. Only by developing a SBOM is it possible to ensure that no security vulnerabilities will be introduced when all the pieces included in the SBOM are combined.

Automating the creation of the SBOM helps ensure it is complete and error-free, and that the analysis of the SBOM will validate the pre-deployment security posture before moving forward with deployment.

Infrastructure and cloud security

In the context of the software delivery life cycle, infrastructure security is about where code and images are stored, as well as the location of the staging and testing environment. Code is, after all, digital information that can be stolen, changed, or otherwise manipulated. Code must be treated with the same sensitivity and respect as proprietary data. There are several best practices related to this, such as that IP addresses should be private and encryption should be enabled.

While these physical security issues are typically handled by IT or a cloud provider, the key question from a devsecops perspective is whether developers are following company policies when setting up environments. For example, when spinning up infrastructure for the mobile banking team, are all the mobile infrastructure-specific policies being followed? Are all the configurations correct?

A devsecops best practice here is storing all the configurations somewhere, such as in a Git repository, and then automating the provisioning by using infrastructure-as-code tools, such as Terraform, to ensure everything from the request to provisioning follows policy and is properly configured and secured.

Process security

Every software development process or workflow can be considered a pipeline that requires a sequence of activities, like a flowchart. Pipeline security challenges include controlling who can create pipelines, who can modify pipelines, who has read access, and who has write access.

There are two key best practices here. First, devsecops must be able to implement guardrails to ensure only the right people have access to the pipeline at the right time. This is done through role-based access control (RBAC), which enables only authorized people with specific roles and permissions to have access. RBAC, which requires integrating devsecops workflows with the enterprise’s user management system (such as Active Directory), ensures consistent enforcement of compliance rules.

Second, companies can take process security to the next level by establishing separation of duties, which may be required for Sarbanes-Oxley or other compliance standards. For example, “A developer cannot approve the deployment of his or her own code to a test environment. The developer must check in the code, which is automatically scanned and moved to image creation, where it must be approved by a manager before the creation takes place on a test server” is an example of separation of duties best practice. The enforcement of such policies can be automated, and this too is enabled through RBAC.

Individual and collaboration security

Similar to securing processes, ensuring secure access for individuals and team collaboration starts with managing user access by enabling RBAC. Individuals participating in software development should have different access rights based on their role, whether developer, tester, manager, etc. This gets particularly complicated in a large distributed environment, where multiple teams contribute to an application, where multiple users contribute to multiple microservices that are combined together in different ways for different applications, and where multiple teams work on multiple applications using different tools and different technologies.

For example, the access rights of a mobile banking team are likely to be very different from those of a risk management team. That is, a mobile banking team probably should not have access to a risk management team’s Git repository. Meanwhile, a manager may have read-only access to both repositories, while a build management team may have full access to both.

In addition to enabling RBAC, it’s important to secure the devops tool chain by automating integration with a secrets management system, such as Vault. This ensures secure access to secrets and eliminates the possibility of secrets getting exposed within the pipeline, which puts assets at risk.  

Continuous development security

Securing continuous development processes is an extension of collaboration security. In most organizations today, multiple individuals on multiple teams write code every day — fixing bugs, adding new features, improving performance, etc.

Consider an enterprise with three different teams contributing to the application code. Each is responsible for its own area. Once Team 1 checks in updated code, the build manager needs to ensure that this new code is compatible with code already contributed by Teams 2 and 3. The build manager creates a new build and scans it to ensure there are no vulnerabilities.

With so much code being contributed, automation is critical. Only by automating the build creation, compatibility, and approval cycle can a business ensure that each step is always taken and done in a consistent manner.

Busting automation myths

For larger enterprises, which may have thousands of developers checking in code daily, automation is a matter of survival. Even smaller companies must begin putting automated processes in place if they want to keep their developers productive while ensuring the security of their code.

For this reason, businesses must overcome these common fears related to development process automation:

“It’s too costly.” Not true. Automation typically increases productivity and shortens time to value, leading to cost savings.

“Automation will cause developers to lose their jobs.” Wrong. Automation enables developers to perform better and deliver more value to their companies.

“Developers can DIY the automation they need with scripts.” Challenging and dangerous! DIY scripts are error-prone and difficult to maintain, and they are not easily applicable or scalable across teams.

Devsecops is becoming an essential corporate discipline for a reason. Vulnerable code leads to compromises, user frustration, reputation loss, and delayed time to value. Businesses that recognize the importance of security to their success should start focusing on securing their software development life cycle — and should understand the important role that automation can play.

Shashank Srivastava serves as the senior director of solutions architecture and customer success for OpsMx, a leader in intelligent continuous delivery.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.