How to Implement Long Term Open Source Security into Your ALM

In 2017, applications are simply how work gets done. They form the structures through which your employees collaborate, and are the face of your company to the world.

We depend on our developers to keep our apps up to date with a constant stream of new releases and features. In order to meet this demand, development teams turn to open source software for the basic components from which to build their products.

Whether we like to admit it or not, open source comprises between 70-80% of the products we know and love. By building on the work of the open source community with projects like Apache Tomcat, Angular, and many more, developers are able to work more efficiently as it frees them to focus on the proprietary bits that make their products shine.

Shifting left security and bug testing within the CI environment during the software development life cycle has helped to get more secure products out the door faster, and has been widely adopted in the DevOps movement with positive results.

But how do we keep our applications safe and running like a well-oiled machine over the long run throughout their lifecycle after they are out in the wild? Even after a product has made it safely through its release, there is always the possibility that new issues could arise with components that we once thought were safe.

The Challenge of Continuous Monitoring

The open source community is constantly reviewing code, and those thousands of eyes are inevitably going to uncover new vulnerabilities that could endanger your products. These good-hearted coders are diligent in updating the community and the managers of the open source projects about their findings, making the vulnerabilities — and hopefully the fixes as well — public knowledge that can also be utilized by hackers for their attacks.

However, your developers are probably not spending their days monitoring sources like the National Vulnerability Database (NVD) or many of the other spots where new CVEs are published. Chances are that they do not even remember which libraries they have used for their products.

In the aftermath of the Equifax fiasco, there is a general understanding that the old days of just grabbing code and jamming it into your product without building a proper inventory listing and taking security into account are over.

By all accounts, the team at Equifax was unaware that they were even using the vulnerable Apache Struts2 version that led to the breach of their application, allowing for the theft of personally identifiable information belonging to 145 million people.

Simply put, ignorance of vulnerable components in your products is no defense when it puts people’s data in harm’s way. The series of hearings that the Equifax leadership was forced to attend, the resignations, and overall harm that was done to the company’s reputation all point to the fact that the public does not care that you could be bothered to stay up to date on new vulnerabilities due to your busy release schedule.

Historically, one of the primary reasons why security around open source has been an issue is that developers never really felt that it was their concern. They were always more focused on building a product that worked (more or less) and getting it out the door.

Afterall, there was the security guy who would have to clean up the mess further down the pipeline, right?

For developers, manually monitoring their inventory is just impossible, especially at scale. So how do you check this crucial box off your list without waterlogging your team?

Embracing Automation for Long Run Security

The model has changed now, and developers are expected to take more of an ownership over the security of their products.

The fact is that correcting many of these security mistakes like using components with known vulnerabilities further down the development pipeline adds costs and stress to the software development life cycle. Tearing and replacing components because they are vulnerable or do not meet the organization’s policy on licenses are a preventable waste of time and resources that could easily be managed for embracing a healthier ALM process. OWASP drives the importance of adopting better security practices for open source usage home with their Top 10 list, sticking with their warning against “Using Components with Known Vulnerabilities” where they note that, “Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.”

What is needed is an automated way to identify open source components, including dependencies, in your products, and receive alerts about newly discovered vulnerabilities so that you can go in and make the necessary adjustments with patches and updates.

Using the available tools, developers can receive automated lists of all the components in their inventory, and receive alerts when a new vulnerability is discovered.

Your ALM Checklist

We understand that making a change in how your team builds software can be a challenge, and implementing security measures for your open source components can feel like an added burden.

Here is a quick list of tips of where automation can really come into play that will help you cover your security needs from the time you start collecting your open source libraries through their release and beyond.

  1. Know your code: Implementing a solution for automatically detecting all the open source components in your software is a must. It is pretty hard to protect yourself if you do not know what you have in your products.
  2. Solidify Policies for your Build: This is your sanctum sanctorum. No library, dependency, or component that fails to meet your policy for vulnerabilities should be allowed to enter your environment. This process too should be automated so that the administrator can set policies that are enforced team-wide.
  3. Test: DevOps has gone a long way in promoting the need for increased testing to see how code performs, helping to cut down on issues that can arise after release. The same motto should hold true for your open source. Test, test, and then test again to detect issues while they are still cheap and easy to fix.
  4. Release like a pro: Getting your software out the door is just the first step of your product’s journey. Your users depend on your team to provide them with updated documentation of the various open source components that you incorporate in your products, giving them a simple way to know that both you and they are in compliance with all licenses and up to date in covering security concerns.

About the Author

Rami Sass, CEO of WhiteSource, is a highly experienced entrepreneur and executive with a vast knowledge and immense expertise in defining innovative products, leading technology groups and growing companies from seed level to business maturity. He has a rich academic background with a degree in MSc and BA in Computer Science. Prior the inception of WhiteSource, Rami founded Testology and before that he has led development efforts at both CA and at Eurekify, which was later acquired by CA.