What Changes for Developers and Security Teams – InApps 2022

Prisma, from Palo Alto Networks, sponsored this post, following its Cloud Native Security Live, 2020 Virtual Summit held Feb. 11, 2020.

It is easy to understand why it is critical to integrate security at the very beginning of the production pipeline. But even so, security is still often left out of the equation at the beginning of the cycle. The gap is mainly attributed to the often relentless pressure placed on developers to meet ever-faster deployment and update cadences. Any potential speedbump is understandably a threat — which can include a perceived risk of security teams imposing delays in application and update deployment schedules.

“Most organizations’ software development teams have a singular focus on adding new features to their applications and at the fastest possible pace,” Matt Chiodi, chief security officer of Public Cloud at Palo Alto Networks, said. “It’s not necessarily that security is in the back of their minds, it’s just not their primary focus or responsibility.”

Examples of organizations opting for faster development speed at the expense of security are manifest in a number of ways. A recent Palo Alto Networks’ wide-scale study revealed, for example, how organizations typically introduce vulnerabilities into their infrastructure as code (IaC) templates. The analysis revealed how, among hundreds of thousands of publicly available IaC templates commonly in use to build and port applications to the cloud, about 200,000 had at least one medium- or high-severity vulnerability.

These sobering statistics only serve to underscore what many, if not most, DevOps security and development teams already know or suspect. However, the mechanics of what must be done to successfully make the “shift left” often remains a work in progress if it is even adopted at all. How to get started implementing security practices and automated checks at the very beginning of the production cycle to prevent the release of vulnerabilities during the initial stages of development is a struggle for many organizations.

Automate and Scan

Conceptually, the production pipeline process is straightforward. A development team typically goes to the whiteboard, designs the application and infrastructure they want to build and then translates it into code. But as the code gets pushed through the pipeline and eventually ends up in production environments as part of the continuous integration and continuous delivery (CI/CD) processes, Chiodi says there remains a critical fourth step: “Making sure, at a minimum, you’re scanning the IaC template for vulnerabilities,” Chiodi said.

“Many development teams understand the requirement to scan traditional application code for vulnerabilities,” Chiodi said, “but IaC templates are still new enough that they typically slip under the radar.”

Scanning code for vulnerabilities from the outset, at the beginning of the development process, requires the right tools as part of a “shift left” strategy. Chiodi, for example, advocates giving developers plugins that they can use natively in their workflows. “Don’t try to make them come outside their normal workflow, because you’re going to get pushback. You don’t want plugins or tools to impact their workflows by slowing them down or negatively impacting their being able to complete sprints on time,” Chiodi said. “So, give them tools that work natively in their integrated development environments (IDEs) thereby giving them early feedback even before they submit their code for build.”

With IDE-based tools, the idea, as part of the CI process, is to “try to catch things as early as you can,” Chiodi said. “You still have to do developer education and code reviews, but you want to be able to get their early feedback,” Chiodi said. If developers are creating new containers, for example, the container should be checked into the registry in an automated way as part of the build process and then checked for vulnerabilities.

Palo Alto Networks is adding or updating specific tools and plugins for Prisma Cloud Native security platform in late April to help DevOps teams boost their shift-left as well as post-deployment monitoring capabilities. These include:

• Infrastructure as Code (IaC) scanning: Scans IaC templates with out of the box and customizable policies for insecure configurations.
• Central CI/CD policy management: Sets policies to govern continuous integration (CI) and continuous delivery (CD) workflows directly from the Prisma Cloud dashboard for cloud native security and consolidating cloud risk management.
• Amazon Machine Image (AMI) scanning: Scans for security issues in AMIs before they’re deployed, while providing visibility into the security posture of cloud applications.
• Automatic serverless protection for AWS Lambda: Protects AWS Lambda functions, by automating serverless applications protection.

Security Becomes the Team of ‘Yes’

The “shift left” must involve cultural changes. Security teams, in earnest, might be inclined, for example, to first let developers create their code before they run a security check or other tests. But as the security teams spend time determining whether the code is approved or not for deployment, the development team frets over how the process becomes an impediment to boosting application-deployment cadences. Oftentimes, code might be rejected and sent back, thus bringing deployment speeds to a halt. In many ways, this scenario is the opposite of what should happen in a “shift left” context.

“A lot of security teams have bad reputations because they have been “no, no, no,’ but instead, there should be an agreement upfront that as long as standards are followed and vulnerabilities of a predetermined level are not passed through the build process, developers can continue their sprints without delay,” Chiodi said. “No one intentionally wants to introduce risk into cloud environments.”

Once security tools are organically embedded into the development pipeline, security teams will have more bandwidth to create policies and focus on mitigating risks. Once in place, “you move away from the concept of security having to be involved all the time, which isn’t possible to scale, and having to look over somebody’s shoulder, because now, instead of gates, there are automated security guardrails,” Chiodi said. “The whole concept focuses on putting guardrails around your CI/CD process.”

Security processes as guardrails become fundamentally different from traditional security processes. “I’ve seen a lot of security teams that look to scale their security personnel in proportion to the number of developers. I think embedding is still a good idea, but they can’t possibly look at every single piece of code,” Chiodi said. “The right way to scale and shift left is to turn security policies and standards into code. They then become an automated guardrail, which is naturally part of the development process.”

Shift Left and Keep Right

Never say never, but at this time, no security plugin or tool will secure application deployments eternally. Security teams will continue to monitor deployments and infrastructure for vulnerabilities — and they will occur at some point and somewhere, of course. Standard hygiene, such as standard patching and two-factor authentication will remain facts of life indefinitely.

“Doing this won’t take care of all your security issues but it will likely significantly reduce your chances of ending up in the headlines,” Chiodi said. The idea is that “by shifting security left you can remove low-hanging fruit and not become one of the statistics.

In the event of a major breach or data compromise, plans also must be in place for business operations that need to continue with “minimal disruption even in a scenario, when, for example, the organization is held hostage under a ransomware attack,” Gaurav Rishi, head of product at Kasten, said. “The Ops team must shield developers from needing to instrument their code or perform special recovery functions even in this extreme scenario. Instead, the Ops team should have a self-service portal that has strict RBAC implementations so that they can transparently ensure that.”

It is also critical to assume vulnerabilities can and always will surface, regardless of how locked down your code is at the very beginning of the production cycle. In other words, security teams, in addition to shifting more of their attention to the very beginning of the production cycle — to the “left,” as described in detail above — must not forget to maintain extreme vigilance in managing security at the other end of the production cycle — to the “right,” such as when managing deployments and infrastructure.

The idea is thus to “remove as many issues as possible either before they are introduced or early in the development lifecycle,” Jack Mannino, CEO at nVisium said. “However, while we ideally want to catch security bugs as far to the left as possible, in reality, some issues may not manifest themselves until you move further right in the life cycle,” such Mannino said.

Conclusion

DevOps teams have the opportunity to “shift left” security processes in such a way that will not negatively impact developers’ needs to deploy applications and updates at ever-increasing cadences. In order to achieve this, organizations must first adopt the requisite security tools and plugins to automate security checks and set policies at the very beginning of the development lifecycle. Cultural and mindset changes within DevOps are required as well for this to happen.

“Creating DevSecOps as a culture isn’t impossible,” Chiodi said. “However it does take a focus on culture, transparency and shared goals and metrics. Whether you are a team leader or right out of college, you have the power to bring your organization one step closer to DevSecOps as a culture.”

For more insight from security thought leaders, Cloud Native Security Live, 2020 Virtual Summit is your opportunity to learn from the experience and expertise of developers, DevOps pros and IT leaders who all have so much at stake in container technologies and DevSecOps. Hosted by Prisma, from Palo Alto Networks, in partnership with InApps, you can still virtually attend this event held Feb. 11, 2020, for a full day of discussions about cloud native security — brought to you online wherever you may be.

Feature image from Pixabay.