SwampUP: DevOps Needs Guardrails, Not Gates, for Security

Baking security into DevOps processes (via “shift left”) continues to be a challenge for many fast-moving shops, though some smart thinkers at JFrog‘s recent SwampUP virtual conference have a few ideas on how to make it happen.

The question of who owns security in the DevOps process goes back at least until 2012, when DevOps pioneers Gene Kim and Josh Corman suggested the term at the RSA security conference.  Shifting the burden of securing their applications (“shift left”) seems like a big ask for employers who are already tasked with being full-stack developers, especially when they are ever more reliant on externally developed open source software libraries.  Down the (virtual) hallway, security teams are busy keeping the networks, data, cloud presence and end points secure. Application security is pretty far down on their priority lists.

But DevOps, and DevSecOps by extension, is not just about tools, but also about the people and processes and governance, and the way we add security into the DevOps process has been flawed, argued Alyssa Miller, S&P Global Ratings business information security officer  and author of the recently published “Cyber Defender’s Career Guide,” in her presentation at the virtual conference.

Traditionally, the approach security teams have taken is to set up gates between each of the steps in a continuous integration and deployment (CI/CD) pipeline, she said. Static analysis should be done when the code is committed, and the last step before the app moves to deployment is to do dynamic testing. If potential security weaknesses are found, then the application can’t proceed.

“This is what breaks DevSecOps. This is what breaks the CI/CD,” Miller warned of this approach. It causes long feedback cycles, because the code is kicked back, and the developers are asked to fix the issues immediately. “Gates break this model because gates threaten to stop us in each of these phases. They threaten to push us backwards.”

“We have to stop thinking about security as gates between our phases. And instead, we have to look at how security integrates into those phases,” she said.

It is not that we shouldn’t use security tools, but they should be integrated in the pipeline itself, she said. The errors that these tests find should simply be added to the existing DevOps backlog, and handled in the next sprint, where they can even take top priority, if serious enough.

👁 Image

In this approach, “We’re not stopping the current flow of the pipeline. We’re just setting up the next run-through to address the vulnerabilities that we discovered in this one,” Miller said. The risk from exposure of these vulnerabilities shrinks the faster the development cycles become.

A big piece of this puzzle is the upfront work that must be done in threat modeling — understanding what the possible attacks points are for a given application. In the best DevOps fashion, threat modeling should be done as a collaborative process, with business managers, developers, operations and security all working together, not on modeling the system as a whole, but just on the specific user stories, which will reveal the weak spots.

“Imagine for a minute, instead of trying to do threat modeling your entire system, you take in each individual user story. And as that user stories is being written, you just bring in basic threat information and make that a part of the user story,” Miller said. Then the threat information can flow directly into the building process. “Identify the crucial assets that are critical to that particular user story and then identify the threats.”

👁 Image

Secure Cloud Native

One alternative to gates may be guardrails in the DevOps process, suggested Peter Bosch, Cisco distinguished engineer, in his own SwampUP presentation.

With the advent of cloud computing, application development has changed. The developer can no longer depend on infosec taking care of application security simply by ensuring that underlying infrastructure is safe. Like Miller, Bosch stressed that the CI/CD pipeline of today has not incorporated security practices, by and large. And conversely, many security teams have little idea of the potential vulnerabilities hidden in the apps that the devs have built.

👁 Image

“There’s no such thing as CI/CD plus continuous security, or an integrated security toolset that goes directly into the IDE,” Bosch said.

Ideally, the idea would be to integrate security directly into the CI/CD process. This can be done by the security team adding in guardrails to the development process, Bosch suggested. The security team, for instance, could provide a set of trusted assets, such as images, serverless services, APIs, configuration settings and supporting toolsets. This would give the security team the opportunity to review and monitor all these specific assets for security vulnerabilities. If a vulnerability is later found in one of the supporting libraries, then the security team can notify, via a Jira ticket perhaps, the developer to update their software.

Bosch demonstrated a Cisco software package called Secure Cloud Native (Secure CN) that could give developers a wider picture of how their cloud native applications are working from the perspective of either the container, image, an image layer or an API. The application’s external activities are monitored from the metrics coming in via the Envoy proxy running on an Istio service mesh. The interface can show how the applications is put together from the different components and vulnerabilities or other issues there may be with the application itself.

👁 Image