• Home
  • >
  • DevOps News
  • >
  • DevOps Needs Guardrails, Not Gates, for Security – InApps Technology 2022

DevOps Needs Guardrails, Not Gates, for Security – InApps Technology is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn DevOps Needs Guardrails, Not Gates, for Security – InApps Technology in today’s post !

Read more about DevOps Needs Guardrails, Not Gates, for Security – InApps Technology at Wikipedia

You can find content about DevOps Needs Guardrails, Not Gates, for Security – InApps Technology from the Wikipedia website

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.

Read More:   Operationalize the Enterprise Developer – InApps 2022

“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.

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.”

Read More:   Dot NET vs Java - Which is better?


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.


“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.

Read More:   The Next Step after DevOps and GitOps Is Cloud Engineering, Pulumi Says – InApps Technology 2022

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: JFrog.

Source: InApps.net

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download


      Success. Downloading...