Those who know me understand that I try to find a little positivity in every moment. However, it must be said that the escalation of cybersecurity incidents in recent years has made it quite difficult to find the silver lining.
A simple look at some of the data-driven insights into our predicament reveals something from a powder keg: over 33 billion records will be stolen by cybercriminals in 2023 alonean increase of 175% compared to 2018. The cost of cybercrime is expected to reach $10.5 trillion by 2025and the average cost of a data breach has skyrocketed to US$4.24 million (although we only have to look at incidents like Equifax or Solar Winds to see that it can be much worse).
We’ve spent a lot of time waiting for a hero to come save us from cybersecurity villains who seem to hold more power than we thought possible even 10 years ago. We expect more cybersecurity professionals to join us, but it’s a gap we can’t fill. We’ve been waiting for the silver bullet tool solution that promises to automate us away from growing risks, but it hasn’t and is highly unlikely to exist. We are waiting for our Luke Skywalker to help us fight the dark side.
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, working with White House officials, top CISOs, and other top executives from 37 private technology companies. With this combined support in both action and funding, the open source software security standard is set to become much stronger.
Of particular interest is the emphasis on basic training and certification at the developer level, as well as 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.
Developer Security Certification: Are We There Already?
If there’s one thing we’re sure of, it’s that skilled security developers are still in short supply. 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 policies within organizations. Add to that developers who don’t have much reason to prioritize security (their training is inadequate or non-existent, it takes longer, it’s not part of their KPIs and their main concern is doing what they do). do best: build features) and you have development teams ill-prepared to truly manage security at the code level, or play their part in a modernized, DevSecOps-centric software development lifecycle (SDLC).
If we look at the open source software security mobilization plan, the very first part of the ten-point plan is developer security skills, to “provide everyone with basic software development training and certification.” secure software. They highlight issues we’ve been discussing for some time, including the fact that secure coding is the MIA of most tertiary-level software engineering courses. It is incredibly encouraging to see this supported by individuals and departments who can change the industry status quo, and with 99% of the world’s software containing at least some open source codethis development area is a great place to start focusing on security training for developers.
The plan cites revered resources like the OpenSSF Secure Software Basics course, and the vast and long-standing resources of the OWASP Foundation. These information centers are invaluable. The proposed deployment to disseminate these developmental developer materials involves bringing together a wide network of partners, in the public and private sectors, in addition to partnering with educational institutions to make secure open source development a key feature. of the study program.
As for how they’ll win the hearts and minds of software engineers around the world, many of whom have seen hardened security as something that isn’t their job or priority, the plan details a reward and recognition to target both developers who maintain open source libraries, and working engineers who need to see the value in security certifications.
We know from experience that developers respond well to prompts, and that tiered badge systems indicating progress and skill work just as well in a learning environment as on something like Steam or Xbox.
However, what is concerning is that we are not addressing one of the fundamental issues, which 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 might disrupt work which is the number one priority. . Enabling developers requires them to continuously engage with the course material, and for this to be successful, it must make sense in the context of their day-to-day work.
The fundamentals are one thing, but once you’ve mastered that layer, what’s next? The learning paths for developing security skills are numerous, even at the level of developers, and for them to share the responsibility for security in a meaningful way, courses must enable them to acquire practical, specific and Understand the impact of poor coding patterns. both in their written code and in the potential pitfalls of OSS projects. Until they understand they have the power to close windows of opportunity that can lead to disastrous violations, education and certification may not be taken as seriously as we would like.
Bill of Materials: Does this plan remove barriers to adoption?
Another area 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 Foster the adoption” which explores ways to make this easier for developers. and their organizations to create, update, and use SBOMs to achieve better security outcomes.
As things stand, SBOMs aren’t widely adopted across most verticals, making it difficult to realize their security risk reduction potential. The plan has a brilliant strategy for defining key standards for building SBOMs, as well as tools to facilitate building that fit the way developers work. These alone would go a long way in reducing the burden of another SDLC task for developers who are already spinning many plates to build software at the speed of demand.
What I fear, however, is that in an average organization, security responsibilities can be a real gray area for developers. Who is responsible for security? Ultimately it’s the security team, but the devs have to travel if we want their help. Tasks and expectations need to be clearly defined, and they need time to take those extra steps 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 hold developers accountable for security. It took a “rebel alliance” of some powerful players coming together, but it proves that we are heading in the right direction and leaving behind the idea that the cybersecurity skills gap will magically resolve itself.
This is our new hope, and we will all have to take this structure forward beyond the OSS. I’m ready.