Those who know me understand that I try to find some positivity in every moment. However, it has to be said that the past few years of escalating cybersecurity incidents have made it quite difficult to find the silver lining. 

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

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 10 years ago. We’re waiting for more cybersecurity professionals to get on board, 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. 

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, 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.” 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. 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 the number one priority. 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.

Fundamentals are one thing, but once that layer is mastered, what is the next step? The learning paths for building security skills are plentiful even at the developer level, and for them to share the responsibility for security in a meaningful way, courses have to allow them to get hands-on, specific, and understand the impact of poor coding patterns in both their written code, and potential pitfalls within OSS projects. Until they understand that they have the power to close windows of opportunity that can lead to disastrous breaches, education and certification may not be taken as seriously as we would like. 

 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 creation, 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. I’m ready.