4 Steps to Ensure Your OSS Security Program Doesn't Flop

It should come as a surprise to absolutely no one that works in software that open source software (OSS) is ubiquitous in most Agile development shops. While it would be foolish to omit the benefits of integrating open source libraries into your applications, it would also be downright irresponsible to omit the potential risk. That’s not to say that open source is more insecure than proprietary code, but you can’t ignore that software is not always built with security in mind. Couple that with the fact that many open source libraries integrated into production never see any sort of patching or updates, and you have a recipe for a breach once a new vulnerability is disclosed. We’ve talked about the tools you need to test for OSS vulnerabilities, but that’s only half the battle. You need dedicated processes and people to build a programmatic approach to getting a handle on open source risk.

1. Understand Your Applications’ Bill of Materials

Having a bill of materials for your application portfolio is the first order of business to understanding your open source risk. If you can’t remember if your application uses Apache Commons Collection v. 3.2.1, don’t worry, you’re not the only one. Software Composition Analysis is the most obvious method to understand what open source libraries you have deployed, the version being used, and whether that version has any known vulnerabilities. Maintaining a master repository of open source components is never a bad idea either. Should a zero-day vulnerability be disclosed, it’s good practice to have a single source of truth to cross-check if you have that particular library deployed, and who the application owners are so you have a clear incident response plan.

2. Establish a Sustainable OSS Security Policy

Draconian application security policies have proven to be ineffective as it slows down delivery and can sometimes cause rifts between the development and security teams. Yet, without internal governance, your open source security program could quickly become an afterthought. A comprehensive and enforceable security policy can help establish the rules of engagement for implementing open source, without alienating your developers. A good example would be disallowing any open source vulnerability that surpasses a certain CVSS (Common Vulnerability Scoring System) score which is usually graded on a scale of “low” severity to “critical” severity. This is where keeping an inventory of your open source components comes into play as it gives visibility into risky components that are eligible for blacklisting. For software vendors, having a policy in place to dictate how far back you are going to patch should a vulnerability be discovered is an important factor to keep in mind for customers who may be using legacy versions of your product.

3. Foster Security Champions from Within

As the DevSecOps movement becomes more mainstream, having someone who can “speak developer” will be paramount to ensure that there’s a mutual understanding between Security and Development when it comes to implementing open source. Security Champions are a new concept within the world of software development but designating an internal champion within your development organization can help foster collaboration between your Security and Dev teams. Security Champions serve as the standard bearer for secure code development and can be a critical resource for empowering your dev team with training, mentorship as well as serve as an ambassador to the security organization. With regards to open source, Security Champions are your point person in your incident response plan. Should a vulnerability be disclosed, your Champion can take point on identifying the risky component(s), flagging any compromised applications, patching, and ongoing training for the rest of the development team.

4. Integrate Security Into the SDLC from Day One

At this point, most would agree that automating security into the development process is an industry best practice, but it should also be known that there are significant cost savings to integrating security from Day 1. A 2017 study from the IBM System Science Institute revealed that the cost to fix a security flaw found in the implementation phase is around 6 times more expensive than fixing one in the design phase. This principle extends to open source as we’ve seen what the potential costs of neglecting to check for open source vulnerabilities can be. We often associate security automation to proprietary code but open source security can, and should, be baked into the development process as soon as coding starts. Even simple patches to open source components can prove costly post-deployment as updating to a new version can have impacts on the overall architecture of the application. This can be avoided by ensuring that risky components aren’t being introduced into your environment from day one of development.

As Much as It’s About Technology, It’s More About People

An open source security program is only as good as the processes that govern it and the people who are willing to take accountability for its success. Taking the steps to empower your team to take ownership of open source security while also fostering a culture of collaboration will catapult your program to new heights.