If you’ve been actively involved in software development in recent years, then you should be aware of the term “DevOps.”
The name and its practices have been increasingly adopted in development circles for many years, regularly seeing software released both earlier and more often.
What’s more, the software produced often has fewer defects and failures — up to 50% less according to a report from Puppet Labs.
If you’re not aware of what DevOps is, Vaishnavi Mohan, from the Technische Universität Darmstadt refers to it as:
…improving the performance of software development operations by involving the development team and the operations team in one process. This helps to increase the frequency of deployments, which helps to service the customers faster.
However, the ability to deploy changes more quickly is a double-edged sword.
Consider for a moment what happens when changes contain bugs — or security holes?
If we’re not careful and don’t have systems and practices in place to guard against them being released, we have the ability to bring our systems down much more quickly.
And what about deployment processes?
Do they contain security holes as well?
Consider the information which might be stored there, information which could potentially be exploited by or leaked to malicious actors?
Without wanting to make light of the situation, the episode from Commit Strip below sums it up rather eloquently
In saying all this, I’m not attempting to downplay the clear benefits which DevOps has delivered.
However, we need to be careful to ensure that what we’re deploying is secure.
The question is How?
For security to work, just like testing, it has to be an integral part of the development and deployment process.
It can’t be considered an add-on, an optional extra, or something that we get around to when we have time and no other competing demands.
For these reasons, and several more, the SecDevOps movement began.
What is SecDevOps?
SecDevOps (also known as DevSecOps and DevOpsSec) is the process of integrating secure development best practices and methodologies into development and deployment processes which DevOps makes possible.
Steve Arychuk at New Relic describes it well:
SecDevOps — sometimes called “Rugged DevOps” or “security at speed” — as a set of best practices designed to help organizations implant secure coding deep in the heart of their DevOps development and deployment processes. …It seeks to embed security inside the development process as deeply as DevOps has done with operations.
Going further, according to TechBeacon SecDevOps consists of two distinct parts:
1. Security as Code (SaC): which refers to the building of security into the tools that exist in the DevOps pipeline. This means automation over manual processes. It means the use of static analysis tools that check the portions of code that have changed, versus scanning the entire code base.
2. Infrastructure as Code (IaC): defines the set of DevOps tools used to setup and update infrastructure components. Examples include Ansible, Chef, and Puppet. …With IaC, if a system has a problem, it is disintegrated, and a new one (or two) are created to fill the spot.
They go on further to say that:
The hinge to success for DevOps security lies in changing the underlying DevOps culture to embrace security—with no exceptions. As with any other methodology, security must be built into DevOps.
Unpacking that, to implement SecDevOps we need to revisit our existing DevOps pipelines, processes, and culture and ensure that security is integrated just as deeply and tightly as any other development consideration.
We need to ensure that we don’t consider security as an afterthought and that, across an entire organization, the benefits of implementing a security mindset — as well as the consequences of not doing so — are well understood.
What’s the Difference Between SecDevOps, DevSecOps, and DevOpsSec?
Before we continue further, I want to clarify this question, as you’re likely to see the terms used a lot, and which may cause some confusion.
There’s been some discussion in the community about what the right term to use is.
Should it be SecDevOps, which implies a secure version of DevOps?
Alternatively, should it be referred to as DevSecOps or one of the other two variations, which implying security more specifically from the development perspective?
Personally, SecDevOps makes far more sense because it’s a more natural and intuitive extension of the existing DevOps term.
I’d like to think that, in time, when security best practices are thoroughly integrated into DevOps, that the “Sec” prefix can be dropped, as it will no longer be necessary to make a distinction.
I hope this resolves any confusion you may have.
How Can SecDevOps Be Implemented?
With the description of what SecDevOps is and the motivations for it out of the way, to apply it correctly, changes to tooling, processes, and organizational culture are necessary. Let’s consider each in turn.
Tooling
- Automate security audits. Use scripts, static and dynamic analysis, composition analysis, and integration of testing within existing tools
- Detect security flaws as soon as possible. The sooner a security flaw can be detected, and the further away they are done from production (or the client’s computer), the better it is, and the cheaper it is to resolve
- Regularly break the build. Ensure that tools can spot and flag security flaws which result in broken builds, just like how failing tests already work.
- Have accurate audit report results. Ensure that reports of security flaws are accurate; otherwise, faith and trust will rapidly erode.
- Use composition analysis. Ensure that you know the security, reliability, and exposure of the packages that you’re building your software on, as well as when they need to be avoided or replaced. Use tools that automatically validate them.
- Focus on instrumentation. Ensure that infrastructure, not just code, can be verified as working and secure; and that it’s replaceable when it’s isn’t.
- Use real-time protection. Ensure that production applications are protected against vulnerabilities that weren’t caught earlier. No software is 100% secure. Avoid solutions that create alert fatigue, false positives or that aren’t integrated into the DevOps tools. Sqreen is, of course, one of them 😉
Processes
To change processes, consider the following four points:
- Establish strong feedback loops. As with any successful process or organization, you need to engender the ability to provide reliable feedback, even if the information delivered isn’t encouraging, or what the team wants to hear.
- Perform regular code audits. Just as with any other code review, such as for quality and standards compliance, security also needs to be reviewed, assessed, and corrected as transparently — and as quickly — as possible.
- Benchmark and review your performance. Like reaching any goal, you have to know where you are and whether you’re improving or declining in the attainment of it. Make sure that you know how you’re doing, and where you still need to improve.
- Have documented procedures for dealing with problems. Eventually, problems do occur. Ensure that you’re equipped to deal with them when they do in an organized and standardized manner.
Culture
To build a SecDevOps culture, consider the following four points:
- Engender a culture of openness and continuous learning. Ensure as much transparency as possible. Ensure that everyone in the team knows what’s going on, and is constantly encouraged to learn more.
- Build strong feedback loops. Ensure that information is rapidly delivered.
- Employ and nurture security evangelists. Ensure that you have people within your teams whose role is to reinforce and to grow security awareness and a security culture.
- Grow autonomy in every team. Ensure your teams can make the relevant decisions necessary to improve consistently.
In Conclusion
SecDevOps is the practice of implanting security deep at the heart of DevOps development and deployment processes.
We need to continue to ensure that security is considered as important as any other modern development best practice.
By knowing about and implementing SecDevOps, I believe we are well on our way to doing that.
I believe that, at least for the time being, maintaining the name, and not dropping it in favor of just DevOps is necessary, because the case for stronger appreciation of and application of security best practices remains as pertinent as ever.
If you’re not already implementing or planning to implement SecDevOps, I strongly encourage you to begin as soon as possible — today, even.
The stated benefits, along with the reduction in cost should provide sufficient incentive and motivation to do so.
If you’re interested in learning more about securing your Docker containers, check out my previous article on Docker Security.
Further Reading
If you’re keen to know anything more about SecDevOps (or DevSecOps or Rugged Software), here are a host of links to sites, blogs, podcasts, Twitter accounts and more which you can use to grow your knowledge.
- http://www.devsecops.org
- http://www.devseccon.com
- Awesome DevSecOps: “a collection of documents, presentations, videos, training materials, tools, services and general leadership that support the DevSecOps mission”
- Secure Coding: The Rise of SecDevOps: a podcast episode discussing Secure DevOps.
- #SecDevOps: The Twitter Hashtag
- SecDevOps: Injecting Security into DevOps: a course teaching how to create more secure applications by utilizing numerous tools and standards.
- SecDevOps Risk Workflow: a book about making developers more productive, embedding security practices into the Software Development Lifecycle and ensuring that security risks are accepted and understood.
About the author
Matthew Setter is an independent software developer and technical writer. He specializes in creating test-driven applications and writing about modern software practices, including continuous development, testing, and security.
