Are we mature enough for the Open Source Software Security Mobilization Plan?

In the current economic climate and threat landscape, I certainly don’t envy the average CISO. They are tasked with delivering safety, compliance, innovation, and business value, while facing an uphill battle with shrinking budgets and increased scrutiny. Perhaps more pressing is the fact that every organization (and its respective development team) sits in varying stages of security maturity, and not all are equipped to put their best foot forward in terms of cyber defense. 

The past few years of escalating cybersecurity incidents have made it quite difficult for security leaders to stay one step ahead. Just glancing at some of the data-driven insights into our growing predicament reveals something of a powder keg: more than 33 billion records will be stolen by cybercriminals in 2023 alone, an increase of 175% from 2018. The cost of cybercrime is predicted to hit $10.5 trillion by 2025, and the average cost of a data breach has skyrocketed to USD $4.24 million (though we only have to look at incidents like Equifax or Solar Winds to see it can be far worse). 

As an industry, we’ve spent a long time waiting for a hero to come along and rescue us from the cybersecurity baddies that seem to hold more power than we thought possible, even ten years ago. We’re waiting for more cybersecurity professionals to get on board and lift us to a higher standard of security program, but it’s a gap we cannot close. We’re waiting for the silver bullet tooling solution that promises to automate us away from growing risk, but it does not and is very unlikely to exist. We’re waiting for our Luke Skywalker to help us fight the Dark Side.

As it turns out, help (and hope) is on the way, in the form of The Open Source Software Security Mobilization Plan. However, we must all take stock and honestly assess if we're mature enough in our organization - and if our development teams have the right level of security awareness and skills - to implement the latest and greatest defensive strategies, especially when they require the support of and execution by the development team.

What is The Open Source Software Security Mobilization Plan?

This ten-point plan was spearheaded by The Open Source Software Foundation (OpenSSF) and the Linux Foundation, in conjunction with White House officials, top CISOs, and other senior leaders from 37 private technology companies. With this combined support in both action and funding, the security standard of open source software is set to become much stronger. 

What is especially interesting is their focus on baseline education and certification at the developer level, and measures designed to streamline internal Software Bill of Materials (SBOM) activities. These are both notoriously difficult to implement in a way that has a lasting impact, which can be attributed in part to growing pains within organizational security programs, and a general lack of security maturity among the development cohort, through no fault of their own. They are in a pressure cooker environment where code volume at speed reigns supreme, in the face of ever more unreasonable deadlines. Adding even more tasks in the form of security asks and SBOM maintenance without increasing the time available for them is a recipe that has failed before it’s even begun, and sadly, it’s more common than we might expect.

So, let’s take a look under the hood.

Security certification for developers: Are we there yet?

If there is one thing we know for sure, it’s that security-skilled developers are still a rare commodity. This is the reality for a number of reasons, namely that until recently, developers were not part of the equation when it came to software security strategies within organizations. Couple that with developers not having much reason to prioritize security (their training is inadequate or non-existent, it takes longer, it’s not part of their KPIs, and their chief concern is doing what they do best: building features) and you have development teams that are ill-prepared to truly deal with security at the code level, nor play their role in a modernized, DevSecOps-centric software development lifecycle (SDLC). 

If we look at The Open Source Software Security Mobilization Plan, the very first stream of the ten-point plan is addressing developer security skills, to “Deliver Baseline Secure Software Development Education and Certification to All” which is essential to build security maturity in development teams. They highlight the issues we have discussed for some time, including the fact that secure coding is MIA from most software engineering courses at the tertiary level. It is incredibly encouraging to see this supported by individuals and departments that can shift the industry status quo, and with 99% of the world’s software containing at least some open-source code, this realm of development is a great place to start focusing on developer training in security.

The plan cites revered resources like the OpenSSF Secure Software Fundamentals courses, and the extensive, long-standing resources from the OWASP Foundation. These information hubs are invaluable. The proposed roll-out to get these materials out there for upskilling developers involves bringing together a wide network of partners, in both the public and private sector, in addition to partnering with educational institutions to make open-source secure development a key feature of the curriculum. 

As for how they will win over the hearts and minds of software engineers worldwide, many of whom have had security reinforced as something that is not their job or priority, the plan details a reward and recognition strategy to target both developers maintaining open-source libraries, and working engineers who need to see the value in security certifications. 

We know from experience that developers do respond well to incentives, and that tiered badging systems showing progress and skill work just as well in a learning environment as they do on something like Steam or Xbox.

However, what is of concern is that we’re not addressing one of the core issues, and that is the delivery of learning modules within an organization’s security program. Having worked closely with developers for much of my career, I know how skeptical they are when it comes to tools and training, not to mention anything that looks like it might disrupt work that is priority numero uno. Developer enablement requires them to continually engage with course material, and for this to be successful, it has to make sense in the context of their day-to-day work.

If we consider an established maturity model like the Software Assurance Maturity Model (SAMM), “Education & Guidance” is a core component of the Governace layer, and there is a key focus on developer education. The model in its entirety is vast, and there are progressive steps in reaching higher levels of maturity. However, the initial stages recommend just 1-2 days of formal training for developers, which is hardly enough to scratch the surface of security awareness. Even then, a recent report by the Enterprise Strategy Group (ESG) revealed that less than half of organizations require developers to engage in formal security training more than once a year. Our own research in conjunction with Evans Data revealed that only 29% of developers believe the active practice of writing code free of vulnerabilities should be prioritized. There is a clear disconnect between how education is delivered and received, and how useful it truly is in bringing about security maturity, especially if developers are not seeing value.

Software Bill of Materials: Does this plan break down the adoption barriers?

Another area that the plan seeks to address is the calamity that often exists around Software Bill of Materials (SBOM) creation and maintenance, with the stream “SBOM Everywhere — Improve  SBOM Tooling and Training to Drive Adoption” investigating ways to make this easier for developers and their organizations to create, update and use SBOMs to drive better security outcomes.

As it stands, SBOMs are not widely adopted in most verticals, which makes it difficult to realize their potential in reducing security risks. The plan has a brilliant strategy to define key standards for SBOM formulation, as well as tooling for ease of creation that fits with how developers work. These alone would go a long way in decreasing the burden of yet another SDLC task for developers who are already spinning a lot of plates to create software at the speed of demand. 

What I fear, however, is that in the average organization, security responsibilities can be a real gray area for developers. Who is responsible for security? Ultimately, it’s the security team, but developers need to be brought on the journey if we want their help. Tasks and expectations need to be clearly defined, and they need time to take on these extra measures of their success. 

From OSS to the rest of the software world

The Open Source Software Security Mobilization Plan is ambitious, bold, and exactly what is needed to drive developer responsibility for security. It took a “Rebel Alliance” of some powerful players coming together, but this serves as proof that we are heading in the right direction and leaving behind the idea that the cybersecurity skills gap will magically fix itself. 

It’s our new hope, and it’s going to take all of us to push this structure forward beyond OSS. However, security professionals must look within themselves, and analyze the development teams that work on the code they are tasked with protecting. They must make an honest assessment of their current capabilities, where the gaps are, and work to create a mature late-stage state that is airtight, proactive, and inclusive of a program that imparts true security skills to the development cohort. Until they are meaningfully enabled, we might still be a little immature in our approach to code-level vulnerabilities.

‍

>> Test your team's security maturity with our hands-on, interactive XSS challenge!