Product security within SDLC is not optional anymore?

Product Security is not a new buzzword. It has been around for decades. Primarily what has changed is how we look into it in light of cyber threats that have evolved over those years and how product security needs to be done then versus now. Essentially Product Security has transitioned from an end-of-development activity into one of the most critical and continuous aspects of product development.

The old approach to security was mostly reactive, focusing on fixing vulnerabilities after they were discovered. As it turned out, with attackers becoming more sophisticated and agile than ever, the volume of vulnerabilities detected in the later stages of software development skyrocketed, drastically increasing the cost of fixes.

At a time when more than 45% of significant data breaches or risk events are tied back to security vulnerabilities within software applications and services, Software development organizations are working in an increasingly regulated environment. This article covers an anecdote that highlights the challenges that engineering leaders face when they fail to adopt secure software development practices right from the start.

Product security is about the processes, workflows and tools used for securing software products that computers, end-users, consumers, and organizations are increasingly reliant on.

A Real Anecdote

As the Head of Engineering at Acme Inc (a fast-growing scale-up that has nearly a million users on its SaaS platform that provides personal finance management and investment), John was heads down for the next major feature release of the Acme platform for more than 50,000 users in their waitlist.

On the Friday evening before the release, he learned about a security bulletin that was doing rounds about a security vulnerability in a popular logging library that, as claimed by various “experts”, was one of the most extensively used libraries ever written.

While not particularly perturbed by this (there were other “bigger issues” that he needs to attend to for the upcoming release), out of an abundance of caution, he sent out a Slack message to his engineering leads, asking them to share a list of projects that have any dependency on this library.

But he was greeted with total silence.

Growing a bit anxious, John set up a Zoom call with his leads to ensure everything is in order. He was sure that this would be a quick call. But...

In the call, he came to know that his engineering teams have no way to know what projects are referring to this library, and in what ways. There is no inventory of code repositories that can be authoritatively tied to products that they have deployed in production, no design analysis that can be referred to get insights into potential blast radius in case the issue is exploited, and no consistent code scans or penetration test results. While various tools are used by his engineering teams, it's mostly best effort and almost all risk assessments and registers are collected via spreadsheets and managed in silos.

Moreover, all of the engineering teams had a massive backlog of unpatched security libraries that needed upgrades, pending design reviews, and code reviews that did not get prioritized due to the fact that it may impact delivery cycles.

John realized that has no way to get a collective view of risks to Acme products, and optimal approaches needed to address these across organizational development portfolios. Despite an increase in the adoption of DevSecOps across his engineering teams, the RoI from these adoptions remains skewed towards organizations with certain specific attributes like team sizes, skills, etc.

As he delved deeper with his team, it became obvious that there are multiple known vulnerabilities in their platform that are protected via obfuscation on the "strong hope" that no one will discover those as they are "hidden".

John suddenly realized that Acme Inc did not have a defined application security program in their organization despite the fact that security breaches have consistently increased over the last 4-5 years. He got genuinely concerned about the impending risk to Acme's customers who have trusted Acme's platform with their data. The thought of getting stuck in the legal suits, and losing out to the competition did come to his mind too. He felt a tad bit annoyed that no one told him how important it is to look beyond just tooling in order to build an application security system that enables development teams to build secure products.

It suddenly became obvious to John that the challenges presented by the immediate security issue related to the logging library are symptoms that were the results of a deeper missing piece in Acme's engineering ecosystem. Acme did not have security included in its development workflows from the start. But to build a security program from scratch will take a long time (to build a process, set up infrastructure, and support workflows to address these gaps). It will incur substantial costs around infrastructure, and an in-house AppSec team to even get off the block. John was smart to understand that deploying tools is a tiny part of the overall setup that he needs Acme to adopt.

(Un)Fortunately, he is part of a vast majority (>86%) of companies that are in the same boat. John desperately wanted to be off it!

Challenges that face engineering leaders like John

Lack of priority for product security programs

Despite the realization of leaders like John about the need to build a robust product security structure, unfortunately, business and security leaders often don’t know how or where to begin when standing up a new program. Some general misconceptions that they run into include

• product security is only about finding bugs in the source code

• over-reliance on penetration testing of high-risk applications

• protecting the perimeter can secure applications

Product security is turning into a casualty of developer speed (& vice versa)

67% of developers surveyed by Secure Code Warrior admitted that they routinely left known vulnerabilities and exploits in their code

The notion that Dev(Sec)Ops is the panacea

Almost 60% of devs are releasing code 2x faster, thanks to DevOps and Security is going lower on the list of priorities. While in DevSecOps, DevOps and Security teams are intended to play together, essentially both are incentivized for different results.

Tools help but when run in silos, these are just noise sources

The Cybersecurity industry probably has more tools than it needs to help companies run adequate product security. If you are able to look through the FUD and buzz, essentially most of the tools are trying to solve the same problems in fundamentally similar ways. In absence of a strategy for making sense of scanning tool data and translating it into clear and actionable information, effectively managing tools and data overload is nearly impossible.

Appsec360 helps companies with this exact problem.

Appsec360 is a Proactive Product Security Platform™ that gives security and engineering teams the ability to improve security as they get better products to market faster. Appsec360 replaces manual efforts, and toil and minimizes the risk associated with software vulnerabilities right from the Ideation stages of your software development setup.