CALMS for DevSecOps: Part 2—Why You Need Automation
CALMS for DevSecOps: Part 2—Why You Need Automation
In the second part of this series, automation takes center stage as well as some of the most popular tools to automate.
Join the DZone community and get the full member experience.Join For Free
In part one of this five-part blog series on DevSecOps, we looked at Culture, the ‘C’ in CALMS, this time, I’m tackling "A": Automation.
“Automation is to DevOps as telescopes are to astronomy.”
I love this phrase and often get a little carried away with the analogy. The stars, I think, are the customers we are looking at, or the value outcomes we want to deliver to them. The astronomers are us, the practitioners of DevOps. The planet we stand on is our organization; the other planets are our partners and competitors. Meteors are threats and incidents we have to deal with. The telescopes are essential in allowing us to see, to gather data and feedback and accelerate the delivery of change.
But we can’t, and shouldn’t, try to automate everything in life. I believe it’ll be quite some time, if ever, before we can all just go and lie on a beach (well, that’s what I’d do, anyway) whilst the machines do all the work. But we can definitely automate to stop doing repetitive and boring work and break the constraints that we see in our work—security, being one of the key constraints. I have some favourite security tools I have learned about with my clients and recommend regularly that help us be more DevSecOps, either by relieving the pressure on the stability (IT Ops) side of the fence or allowing us to ensure security considerations are factored in earlier so as not to slow down the throughput (from development).
All of them should be considered in the context of continuous delivery (CD)—that is, the practice of always having software in a releasable state. Actually, I like to take things further than CD and architect toolchains with my clients that optimize the flow of work from idea to realization; that is, DevOps toolchains that record the idea at the earliest possible opportunity, track it through every step in the continuous delivery lifecycle, including release and operation and feedback on its value into the ideas log (or backlog if you prefer). I call this a DevOps toolchain or the DevOps Loop.
Here are my top tools for DevSecOps (not in any order of preference but more where they might appear in a DevOps toolchain):
For Supply Chain Hygiene: Sonatype Nexus Lifecycle
In my experience, there are two main players in the artifact repository space: Nexus from Sonatype and Artifactory from JFrog. What I really love about what Sonatype have done is how they have shifted left as far as is humanly possible. In another world (it sometimes seems) and a long time ago, I implemented AppScan with a number of clients. And whilst, at the time, it did a great job of automating vulnerability scanning/penetration testing, it did still produce a report that somebody had to read, comprehend and then manually act upon. What Sonatype has done is make it possible for a developer to receive a notification as they access an open source artifact in their repository that tells them if said artifact has a vulnerability deemed unacceptable by their security policies and gives them a link to the one that it would be better for them to use. And if you don’t like interrupting your developers, you can make it part of your CI/CD toolchain instead.
For Coding Standards: SonarQube
Ah, standards! The conversation guaranteed to put somebody’s nose out of joint. SonarQube is often confused with Sonatype (yeah, they do sound a bit similar) but they do different things. SonarQube is as ubiquitous as Jira, Git, and Selenium in my clients and they love it, which always surprises me a little as technologists, particularly developers, are notorious for getting emotional about their favorite methods and tools. I’m a big fan of the sitcom Silicon Valley; witness this scene when uber-geek CEO Richard dumps his girlfriend because she uses spaces and he favors tabs (watch it to the end!). Not many of my clients will "admit" to having coding standards (does SonarQube make it invisible?), even in teams, let alone across an entire organization, because it’s so hard to reach consensus on what "good" is (see also, standardizing a DevOps toolchain) But the conversation isn’t just about making it easier to someone new to the code to understand it. SonarQube automates reviews with static analysis of code to detect bugs, code smells AND security vulnerabilities (and you integrate it into your CI/CD pipeline or DevOps toolchain).
For Continuous Security Testing: GitLab
Thankfully the days of SubVersion are well behind most of us and the new breeds of Git keep our clients happy and in control. Notable is GitLab’s approach to DevSecOps built around the premise that security checks must take place in the development pipeline and not by security experts. As they say:
“Application Security is hard when security is separated from your DevOps flow. Security has traditionally been the final hurdle in the development lifecycle. Iterative development workflows can make security a release bottleneck. Your team doesn't have enough people to test all of your code and hiring more analysts won't automatically reduce the friction between your app sec and engineering teams.”
Their integrated tool covers SAST, DAST, dependency scanning, container scanning, and auto-remediates. In their roadmap they have secret detection, IAST and fuzzing, too. That’s quite a lot of coverage in one tool; building an end-to-end DevOps toolchain is complex and nearly impossible to do with a single vendor (the best you can do is stick to the Microsoft platform if you’re a .Net house, and the Atlassian suite can cover quite a few tool categories too) so every little bit helps.
For Automating Ops: RunDeck
As Damon Edwards, a co-founder at RunDeck said at the Nexus User Conference last year:
“Deployment is not the finish line: it’s the beginning of 24 by forever. What happened was we got, in a lot of places, Agile plus automated deployment. Which was better, but not fully realizing the value of DevOps.”
RunDeck is all about Ops making capabilities available as self-service whilst setting the governance rules, such as security policies, thus, again, breaking constraints and removing unnecessary handoffs “offloading as much of the pressure from IT Ops as possible”. By defining a secure Ops hub, engineers, via controlled self-service can do things like firewall changes themselves, whilst not compromising secrets and identities controlled within the hub. With operations procedures treated as code and also run through the DevOps toolchain, full end-to-end toolchain (from idea to value realization, through the service desk) can be achieved.
For Machine Identity Protection: Venafi
Whatever an organization’s cloud and container strategy, machines are proliferating and with that, the number of X.509 certificates needed to ensure safe browsing and transactions. In a world where SSL and TLS certificates are a hot commodity on the dark web (handily bundled with a range of crimeware) it’s harder and harder to be confident that machine identities are secure. It’s an onerous, tedious and likely to be erroneous job when done by hand so what organizations really need to do it automate it to secure dynamic infrastructure—and throughout the DevOps toolchain, just as Gartner says:
“Don’t force information security’s old processes to be adopted by DevOps developers. Instead, plan to integrate continuous security assurance seamlessly into the developer’s continuous integration/continuous development (CI/CD) toolchain and processes. This is a significant mindset change for information security professionals accustomed to forcing developers to conform to our processes, so it will require several changes, such as never making developers leave their native toolchain environment. This means integrating your testing with their integrated development environment (IDE) and CI/CD toolchain tools.”
For Security Orchestration Splunk Phantom
Splunk is another tool ubiquitous in our clients’ environments and has come a long way from being a mere production logging tool. It sits towards the final stages of the DevOps LoopTM, being mainly about monitoring and value realization. Splunk Phantom is a security orchestration, automation, and response (SOAR) tool that automates tasks, orchestrates workflows, and supports SOC functions like event and case management, collaboration, and reporting.
It uses playbooks as codification of a Security Operations (SecOps) plan. In practice, they’re high-level Python scripts that Phantom interprets in order to execute the mission. Playbooks execute actions, making the security operations process repeatable and auditable.
If All Else Fails: Akamai
Last year, GitHub survived the biggest DDOS attack ever recorded. I’m going to go out on a limb here—if I were a betting woman, I would bet that GitHub’s DevSecOps capabilities are on the sophisticated level of capability and yet this goes to show that there are some kinds of attack you just can’t remediate. Or can you? GitHub’s systems struggled for a whole ten minutes with intermittent outages caused by the 1.35 terabits of traffic per second and then a call was made to Akamai. The attack stopped eight minutes after that when the Akamai service took on its role as intermediary, rerouting all the traffic coming into GitHub, and sending the data through its scrubbing centers to weed out and block malicious packets. You may think of Akamai as a CDN but their perimeter security capabilities could save you if all else fails—and they have integrations into your DevOps toolchain too.
For Visualizing Flow: TaskTop
The next post in this blog series, CALMS for DevSecOps, is all about the “L” or Lean. I’ll be sharing more about the value of focusing on optimizing the flow from idea to value realization and how to remove waste, but I thought I’d introduce TaskTop here as it’s a great tool to help visualize bottlenecks in your flow and security is a big one it frequently highlights. To find out more, look out for/read on to the next post.
Opinions expressed by DZone contributors are their own.