5 ways to implement DevSecOps right now

Heard the term DevSecOps but not quite sure what it means? This article answers the question, what is DevSecOps, and introduces 5 ways you can implement a DevSecOps practice. You’ll also learn what DevSecOps tools you can use to guard against security vulnerabilities. 

Get started with ACG and transform your career with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). The main goal of DevOps is to shorten the software development life cycle and provide continuous delivery with high software quality.

DevSecOps is an extension of the DevOps methodology that emphasizes security at each stage of the software development life cycle. The goal of DevSecOps is to ensure that security concerns are taken into account throughout the software development process, from initial design to final delivery.

There are many benefits to implementing DevSecOps, including improved security, reduced costs, and faster delivery times. However, implementing DevSecOps can be a challenge, especially for organizations that are new to the concept. How can an engineering organization start? Fortunately, a minimal resource investment can pay dividends in security posture.

So, here are five ways you can implement DevSecOps, starting now.

If you're in a security team, one of the most important things you can do to help implement DevSecOps is to get involved in the design process. This way, you can ensure that any security concerns are taken into account from the very beginning. And in turn, this will help to avoid security problems later on in the development process.

A good security team should be easy to connect with, "vending" themselves to other engineering teams within the organization. Reducing the friction of an initial engagement should be a top priority for DevSecOps leadership, building trust with developers and making invites to design reviews a regular occurrence.

A design review is a great way for security professionals to raise possible security concerns. Security experts can spot potential dangers and provide suggestions for mitigating them. Design reviews should be held as soon as possible, ideally before any source code is written. The legacy model of providing a nearly finished application to security teams for review ensures lengthy, manual reviews, and potentially costly refactoring, with security teams forced into a reactionary posture.

One of the biggest challenges in implementing DevSecOps is getting software developers to think of security as an enabler, not a blocker. In many organizations, security teams are seen as “the people who say no.” Worse still, it's often left to the developer and ops teams to find viable solutions, with no further guidance from security. It's unsurprising that security controls are often ignored or worked around.

While it's important for security teams to identify and mitigate risks, they should also be seen as enablers and product collaborators. They can help developers understand how to build secure applications and provide guidance on best practices. 

DevOps has a tenet of people > process > tools; it's important to build the right team with the right skills so that software engineers and security are working in concert.

One of the most important aspects of DevSecOps is catching security issues early in the software development lifecycle. 

As soon as a developer checks in code, it's time to start scanning for potential issues. Using tools like static analysis and supply-chain monitoring can catch low-hanging fruit before it enters run time, massively improving security outcomes.

It's also important to scan containers, dependencies, and open source libraries for known vulnerabilities. There have been several high-profile software supply-chain attacks in recent years. The large-scale security fallout from these attacks should serve as a dire warning to anyone not paying attention to what their software is built on.

In addition to scanning the supply chain, it's important to also scan for credentials and sensitive values in source code. 

Some static analysis tooling provides credential scanning capability as well. So it's important to identify the correct process and tooling to monitor code repositories in your environment for suspicious commits. 

Alerting developers to the presence of sensitive values in their code with a pre-commit hook integration provides developers with an easy path to remediation, without the tedious work of rotating the secret or making changes to pushed code.

Finally, static application security testing (SAST) tools can analyze source code without actually needing to run the code. In legacy development environments, this was often done manually, but DevSecOps should focus on using automated tooling. Static analysis can be used to find vulnerabilities in code, such as SQL injection flaws, command injection, overflows, and cross-site scripting (XSS) vulnerabilities.

Focusing on security early helps provide fast feedback and enables that developer to own the security outcomes of their work, feeding the virtuous cycle of continuous improvement.

The continuous integration/continuous delivery (CI/CD) pipeline is a foundational pillar for any DevOps implementation. A pipeline is the basis on which effective software delivery functions. The testing and deployment automation it enables are crucial to the fast delivery cadence that modern software environments demand.

As a security tool, a CI/CD pipeline is no different. Traditionally cumbersome manual security processes like input validation, integration testing, and behavior monitoring can be integrated into the DevOps life cycle with automation, providing quick, visible results to technical and non-technical stakeholders alike. 

High-functioning DevSecOps teams can even look toward auto-remediation, fixing the low-hanging fruit and leaving engineers free to address more-complex security issues.

In engineering organizations where the DevOps culture is new, or even non-existent, the additional security use case should function as a strong selling point to get leadership buy-in for a pilot program. Automation enables much better leverage of existing staff resources than manual processes, preventing security work from being a bottleneck to business KPIs.

Security efforts in DevOps should be measurable, with quantifiable outcomes that can be used to show the efficacy of security processes and tooling. This data can then be used to make decisions about where to focus future development work. Additionally, sharing these successes with other teams can help create a more DevOps-aware culture company-wide, which can only lead to good things.

Even as more and more security work is pushed earlier into the development life cycle ("shifting left"), it's still vitally important for the entire engineering organization to be vigilant in monitoring application health and behavior, and to maintain a solid operational footprint.

In a mature DevOps culture, there should be no silos between dev, ops, and security. Everyone owns security and everyone works together to secure the applications and systems they are responsible for. But even in a well-functioning team, it's important to keep an eye on what's happening in production. Just because something is built securely doesn't mean it will stay that way. Configuration changes, new dependencies, and code deployments can all introduce new risks that need to be mitigated. And as much as we would all like to think otherwise, humans make mistakes.

So what's the easiest way to make sure the new software service will easily integrate with the company’s monitoring platform? DevOps and DevSecOps staff can engage in early design meetings, pointing out the best practices around libraries and modules to seamlessly integrate with the monitoring stack.

A strong DevSecOps effort with DevOps can also implement automation to enforce correct configuration and behavior in live workloads, highlighting misconfigurations and potential security issues to owners who can proceed to remediate the problem.

So, love the idea of DevSecOps but wondering how to get started? As with any change initiative, starting small is often the best way to create a lasting impact. 

Creating a shared sense of responsibility for security across the entire organization is the first and most important step. From there, it's simply a matter of implementing the tools and processes that will support the team. To upskill on security and process best practices, check out our DevOps and security courses.