The SolarWinds digital supply chain attack began by compromising the “heart” of the CI/CD pipeline and successfully changing application code. It highlighted the major challenges organizations face in securing their applications across the software development lifecycle and is driving increased attention at the highest levels of enterprise and government. In fact, Reuters recently reported that the Biden administration is preparing an executive order outlining new software security and breach disclosure requirements.

As organizations look to strengthen their digital supply chain and protect the applications they develop and use, many are focusing on application secrets – which are ripe targets for attackers and can provide unrestricted privileged access to sensitive systems.

Cloud-Native Apps Expand Security Needs

Today, many organizations are taking a cloud-native approach to building, testing and deploying new applications – whether front- or back-office, consumer-facing, web or mobile. And by embracing DevOps methodologies and automation, they’re quickly moving along the digital maturity curve.

As applications are increasingly built using microservices and run in dynamic, short-lived containerized environments, everything needs to interact with each other – sharing secrets and credentials to securely access resources. The result: a lot more secrets that need to be secured.

What’s more, the powerful DevOps and automation tools developers use such as Jenkins and Ansible to build applications store massive amounts of credentials and secrets within them. This allows the projects, playbooks and scripts managed by these mission-critical “Tier 0” assets to access other tools, services and platforms. All of these tools also require high levels of privilege.

The fundamentals of a formal, effective application security plan should start with business objectives, tools, processes and most of all, data, with the primary driver for securing applications focused on protecting data.

While it is important to surgically address the insecurities in a mission-critical application, it is equally important to continuously upskill the development and security teams, and create a culture where security is not looked at simply a ‘check-the-box’ item.

According to Setu Kulkarni, vice president of strategy at WhiteHat Security, the first step is to identify the right inflection points for injecting application security.

“CISOs need to recognize that no SDLC is built the same and no application is at the same level of maturity within its life cycle,” he said. “We have learned that testing applications continuously in production is critical to identify the real, exploitable vulnerabilities that create the maximum risk of being breached in production.”

Kulkarni noted one way to (almost always) ensure that security does not become an afterthought is to “top & tail” – in other words, make sure that your team gets a voice when the exit criteria is being defined during the requirements phase, and make sure the team is testing in pre-production and production.

“Everything in between is really a negotiation based on the maturity of the SDLC and the application itself. The most consequential best practice is to ensure that the Dev, Sec and Ops teams get accurate and actionable insight from the AppSec tests that are executed,” he said. “After all, the only way to eventually have security operate at the speed of DevOps is through some level of automation, and the efficacy of automation is directly proportional to the accuracy of the data used to drive the automation.”

Doug Dooley, COO of Data Theorem, pointed out that the business driver for AppSec is about privacy, trust and reputation that is directly tied to the brand of those who build and publish the applications.

He noted traditional AppSec testing focused on static and dynamic application security testing, including static application security testing (SAST) and dynamic application security training (DAST).

“However, with a more modern application stack, AppSec programs are starting to factor in third-party risks introduced by open source and software development kits, covered by software composition analysis,” Dooley explained.

Further, cloud-native applications make infrastructure services just another software extension of the application buildout, so many AppSec programs increasingly add cloud security tools, such as cloud security posture management (CSPM).

DEVSECOPS

Enough about culture and on to DevSecOps. What kind of culture allows it to thrive?

1. An important aspect is having a better understanding of the motivators of and detractors in each element. I won’t review those here because they are covered well in this article: https://www.stackrox.com/post/2021/02/devops-vs-devsecops-heres-how-they-fit-together/ But I will say that this topic brings to mind the Stephen Covey quote, “Seek first to understand, then to be understood.”
2. Another cultural aspect is that the model requires people to “fail fast.” Failure must be allowed. It’s not the kind of failure that leads to company ruin, though it may might be personally embarrassing. You know that main network cable that leads to your office, the one with the sign “Do not unplug!”? I’m the guy who accidentally unplugged it. I’m also the guy who returned a laptop without an RMA: it got lost on the return trip, so we never got our money back. I’m the one who worded something poorly in a policy and was glad that someone caught it before it went out. People make mistakes. The allowance of failure will actually lead to encouraging people to fail, born out of the idea that the more they do, the more they’ll fail AND succeed.
3. The culture also has to engender the attitude of “a failure is an event, not a person.” As I referenced earlier – we’re not talking about allowing failures that destroy companies and reputations; I’m talking about failures such as “Oops! I deleted that section of code because I didn’t think it was needed. I’ll get it back ASAP.”

This kind of culture leads, not to diminishing returns, but to cohesion in the team and growth in technical acumen. Do those failures get pointed out and documented? Of course – the team doesn’t really want to spend another 4 hours on another night correcting the same mistake. The person doesn’t get called out, but the failure gets pointed out.

4. The collaborators must be able to expose a vulnerability, have it prioritised, and get it fixed. No naming and shaming, because the goal is not a person’s desire never to fail, but to provide a secure and well-working product.

DevSecOps culture also lends itself to letting those doing the work determine what works best for them, which empowers them to be better professionals. Over time, the team notices patterns in failures and successes, and knows best what product or service would overcome those failures and automate successes.

5. There needs to be ample maker time, so DevSecOps needs to be free from an interrupt-driven culture. There’s a creative aspect to DevSecOps that requires time to think. Anyone in the arts knows that about the sliding scale of concentration (though they may not call it that). On one end is complete focus on a task, but this extreme focus removes the emotional element. On the other end is the emotional scale, but this extreme leaves out the technical part. Toward the middle is the proper mindset, where there’s a free-thinking and open sensitivity required for being creative, in addition to keeping the boundaries of the techniques and protocols, provided by business requirements, customer demand, etc.

Perhaps you aren’t currently part of a corporate culture for proper DevSecOps to thrive, for whatever reason (e.g., current management attitude, a change in leadership). You could work on creating a subculture. You might have a co-worker with whom you can work to make improvements while not negatively impacting the current speed of production. Or you have some leeway to introduce a tool that can help slightly.

6. Technology changes frequently, and those making things happen need to stay up-do-date with training. Embrace it, incorporate it as part of the incentives, make it part of the day, make it happen.
7. DevSecOps are people, and they need rest. There’s only so much and so fast that people can work, and that’s why we use technology. In DevSecOps, technology does not replace people, but enables them to perform their various duties at the speed of light.
8. Metrics have to be as concrete as possible. How does management determine if personnel are doing things right and doing the right things? Judging success by hearsay and feeling is never a rational metric

Regardless of what else it’s called – DevOps with a security focus, DevOpsSec, Secure DevOps – the end result is to have Development, Operations, and Security work together to iteratively create a good and secure product that is delivered timely. When the culture adopts these elements, DevSecOps will flourish.