Are your operations and security functions automated? Have you eliminated manual processes as you start to tighten up your security and controls?
Hi, I’m Peter Nichol, Data Science CIO.
Today we’re going to talk about DevSecOps. DevSecOps is a simplification of the phrase development, security, and operations.
What is DevSecOps?
Let’s begin with a brief explanation of what DevOps is to ensure we’re clear on the difference between DevOps and DevSecOps. DevOps is focused on development and operations. The development part hones in on automation, building or development, testing, and releasing the functionality into your environment. When we add “Sec” in between “Dev” and “Ops,” that reflects considerations of security—for example, ensuring that security is a part of every role. This means that when we make development and operational automation decisions, we have the potential to make similar decisions about the orchestration and automation of security through the DevOps process.
How do DevOps and DevSecOps differ?
DevSecOps adds security to the DevOps process. Previously, your team may have had one or maybe two big releases per year, so security wasn’t such a big concern. The team had lots of time to tighten those security controls and ensure that security procedures and policies were adhered to prior to deployment. With continuous integration, continuous delivery, and continuous deployment—also known as CI/CD pipelines—the team now has monthly, weekly, or even daily releases. In this new environment of constantly releasing customer features, it becomes much more important to evaluate and measure the security footprint on a more consistent basis. This brings forward the concept of DevSecOps to bring security into the development, operations, and release lifecycle.
Where did DevSecOps start?
The idea of continual security goes back to Dr. Joseph Duran, one of the founders of the quality management movement. He introduced the concept of quality by design (QbD). Duran believed that quality wasn’t an aspect of an output of a product or widget. Quality didn’t just happen, and it wasn’t something that needed to be done once a product was created (or features were developed and completed, in our case). Instead, quality was designed into the product, and quality assurance was performed throughout the entire process. It wasn’t a one-off step at the end of the process. By building quality into products, manufacturing companies started to produce higher-quality products with fewer defects.
DevSecOps is as simple as, “design security into the process” or embracing a “security by design” mindset.
We’re able to leverage the same quality-by-design principles that Duran applied so many years ago into how we plan, design, and deploy features that are wrapped, tightened, or hardened by security procedures. We have to design security into our ecosystem. It’s no longer productive to conduct an assessment after features are deployed to determine if code complies with our security standards and procedures.
What does DevSecOps look like in practice?
DevSecOps integrates security into normal development and operations that, in today’s infrastructures, are largely automated. DevSecOps works, in practice, because security workflows apply the development standards and architecture definitions for the organization. This could be things like validating that there are no security gaps in code before it moves into a region. Another example might be validating that the right infrastructure cloud policies prevent unnecessary exposure to sensitive infrastructure, networks, or parts of the security footprint. Ultimately, DevSecOps established many different elements to make sure that security can be streamlined and orchestrated effectively. The result is that rapid security assessments become a regular part of our development and operational environments.
It’s common for a collection of products to be used for DevSecOps orchestration. Here are some of the most popular.
- Commit code to repository: JFrog, snyk, Skim dev, Tallisman, git-secrets, HOUND, Vault, AES Secrets Manager
- Build: Checkmarx, ECG, DerScanner, GitHub, Black Duck
- Deploy: RAPID, acunetix, VERACODE, clair, anchore, DOCKSCAN, KitchenCI, CHEFINSPEC, Signal Sciences, imperva, walarm, Cloudflare, Nagios, Datadog, Gremlin, ChaosToolkit.
What are the benefits?
We’re looking to remove the manual security processes that occur during the deployment or testing of a release. However, just the introduction of DevSecOps introduces new organizational benefits such as:
- The ability to audit
- The ability to be compliant
- The ability to identify issues right away and take immediate action
- Accelerating report compliance
- Formalizing documentation of triggers and decisions made by automation agents
There are many software benefits from having a repeatable and durable security approach that’s streamlined to the degree that the process is mainly automated. While seemingly obvious, the removal of the human factor can significantly reduce variance and production issues. For example, many deployments are performed at odd hours, and, during these hours—whether they’re deployed at 9 pm or 2 am—the team is often not at the top of their game. By adding intelligence automation agents, we remove manual steps that can be defined and repeated with overwhelming precision.
How to get started
After leaders hear about DevSecOps, they’re excited. Their next logical question is, “Now what? How do we start?”
First, define the roles and responsibilities. Consider who’s involved or the roles they play.
Second, establish policies. This answers the general question of, “Why is this new process being introduced, and what’s the desired benefit?” Evaluate which standards are mandatory. Take time to define guidelines and elaborate and expand on best practices. Also, be sure to establish procedures that articulate the step-by-step instructions for compliance.
Third, turn up the automations. You’ve defined the processes, procedures, and implementation standards. Now it’s time to reduce human intervention and narrow the pipeline-error variance through automation.
Fourth, collect evidence. Start making a hit list of what’s working and what’s not.
Fifth, design a constant feedback loop to validate that you’re received timely information or decision making. The feedback loop provides you with a method to discuss lessons learned and introduce positive changes into your environment.
As your week begins, consider whether your DevSecOps pipeline is automated and working in your best interest. Evaluate your operational teams. Ask yourself, “How can the team be a little bit more effective by exploring DevSecOps?” Taking time to automate your DevSecOps environment helps you reach your next organizational win!
If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!
Hi, I’m Peter Nichol, Data Science CIO. Have a great day!