Putting DevOps Security Into Practice: 10 DevSecOps Best Practices

Once upon a time, the main focus of IT engineers was on system administration. Then, the introduction of DevOps in the 2000s extended the focus of many IT engineers to include the entire software delivery pipeline. Even more recently, DevSecOps came along and added security to the mix – with the result that people who once would have thought of themselves as SysAdmins now have a leading role to play in software security, too.

To prove the point – and to explain what an effective approach to DevSecOps looks like in practice – let’s walk through how SysAdmin roles have changed over the years, as well as ten key DevSecOps best practices that today’s IT engineers should follow to put the DevSecOps philosophy into practice.

In this article:

From SysAdmin to DevOps
DevSecOps: Bringing security to DevOps
10 DevSecOps best practices
Automate DevSecOps: Security and speed without compromise

From SysAdmin to DevOps

Until the later 2000s, most IT engineers thought of themselves primarily as system administrators, or SysAdmins. Their main focus was on setting up, monitoring, and supporting hardware and software systems. They didn’t play a major role in software development or delivery.

This changed with the advent of DevOps during the first decade of the new millennium. Because DevOps emphasizes close collaboration between engineers who develop software and those who manage it, it pushed SysAdmins to become more involved in all aspects of software delivery. Instead of simply managing software post-deployment, SysAdmins in the age of DevOps became responsible for helping to plan, design, and deploy software, too.

This is part of the reason why it’s rare to find “SysAdmin” in job titles today. Roles like “DevOps engineer” have become much more common.

DevSecOps: Bringing security to DevOps

In the early years of DevOps, there was one critical gap in the focus of many DevOps teams: Security. That’s because DevOps itself doesn’t address security risks. It focuses only on bringing efficiency to software delivery via collaboration between developers and IT teams.

This is why, starting in the early 2010s, people began talking more about DevOps security – a conversation that ultimately led to the coining of the term DevSecOps. DevSecOps aims to make security an integral part of the software delivery lifecycle, and to encourage collaboration between security teams alongside software developers and IT engineers.

This means that if you work in virtually any kind of IT role today, you’re likely expected not just to embrace the DevOps mantra, but to adopt DevSecOps practices, too. Even if security is not your specialty, it’s something you should help support.

10 DevSecOps best practices

How, exactly, can you do that? How can folks who are not security experts help their organizations implement DevSecOps? They can start by adopting the following DevSecOps best practices.

#1. CI/CD integration

To enable a collective focus on security across all stages of the software development lifecycle, today’s teams should integrate security processes – such as vulnerability scanning and risk monitoring – directly into their Continuous Integration/Continuous Delivery (CI/CD) operations. Integrating security into CI/CD helps ensure that security becomes deeply embedded into software delivery, rather than existing as a siloed process.

#2. Comprehensive security testing

The security tests that support DevSecOps should be comprehensive. This means they should include a range of different types of tests – such as source code scanning, binary scanning, and runtime monitoring – to maximize an organization’s ability to detect risks.

#3. Continuous security testing

Security tests should also be continuous, meaning they occur on an ongoing basis. Scanning periodically or only at certain points of the CI/CD process – such as just before deployment – isn’t enough to catch all risks. It may also lead to delays in software delivery because fixing issues can be much more complicated if teams don’t detect the problems until later in the CI/CD process.

#4. Shift-left security

Speaking of avoiding delays, organizations should also embrace shift-left security. Shift-left security means beginning security tests as early as possible. For instance, rather than waiting until all of an application’s source code has been implemented to test it, engineers can start tests as soon as individual units of code are complete.

Shift-left security is valuable because it increases the chances of finding issues when they are easier to fix. In turn, it reduces the risk of major delays or inefficiencies due to security issues.

#5. Shift-right security

It’s not enough to shift security only to the left. Teams should also shift right, which means implementing rigorous security tests and monitoring post-deployment, too. Shift-right security helps detect risks that slipped by earlier tests and reduces the chance of breaches against production apps.

#6. Compliance alignment

The best DevSecOps strategies align with whichever compliance mandates an organization faces. For instance, if you are subject to a compliance law like PCI DSS (which generally applies to businesses that process card payments), the security controls that engineers create as part of their DevSecOps strategy should reflect PCI DSS requirements.

#7. Security training

Most developers and IT engineers are not security specialists, and it’s not realistic to expect them to master all elements of software security on their own. Instead, organizations that want to excel at DevSecOps should invest in training to help all of their stakeholders understand security best practices.

#8. Secure secrets management

Poor management of secrets (meaning data such as passwords and API tokens, which can be used to login into systems or decrypt sensitive information) can lead to major breaches. To manage this risk, teams that adopt a DevSecOps strategy should establish clear policies for managing secrets, such as storing secrets in a secrets management tool configured with granular access controls.

#9. Threat intelligence

Different organizations may face different types of threats. For example, in some cases, threat actors may target companies based in certain countries, or those that operate in certain industries. Threat intelligence provides insight into the specific threats a particular organization faces. Using this information, teams can anticipate how they might be attacked and erect defenses accordingly.

#10. Developer experience

Making the most of DevSecOps means ensuring that security processes don’t get in the way of development operations or frustrate developers. To this end, teams should invest in reducing friction between development and security processes. Automations can help. So can strategically timing when security scans occur to ensure that they don’t delay or disrupt development workflows.

Automate DevSecOps: Security and speed without compromise

To be sure, implementing all of the DevSecOps best practices described above in a smooth, efficient, and scalable way is no mean feat.
But with solutions like the Aqua DevOps security platform, putting DevSecOps into practice falls within the reach of any team – even those who are not security specialists. Aqua makes it easy to implement a comprehensive set of security tests and scans that cover all stages of the software development lifecycle. In addition, features like risk prioritization and remediation guidance help teams respond to security problems efficiently and ensure that security doesn’t come at the expense of fast software releases or the developer experience.