Paul Roberts (@paulfroberts) at InfoWorld recently shared his perspective on “5 big security mistakes coders make”. First on his list was trusting third-party code that can’t be trusted. Paul shares:
“If you program for a living, you rarely -- if ever -- build an app from scratch. It's much more likely that you're developing an application from a pastiche of proprietary code that you or your colleagues created, partnered with open source or commercial, third-party software or services that you rely on to perform critical functions. These functions could range from licensed presentation and graphical interface elements to user authentication and encryption (think OpenSSL).
Often, third-party components are poorly managed and rife with exploitable vulnerabilities that may have gone unnoticed. Yet most development organizations can't even say for sure what third-party components they're using, let alone whether they were audited for security holes.
What's a developer to do? Writing from scratch isn't an option, but neither is crossing your fingers and hoping for the best. At the least, review recent guidance on ensuring the reliability of third-party software. For example, check out the U.K.'s Trustworthy Software Initiative and the Financial Services Information Sharing and Analysis Center's (FS-ISAC) Appropriate Software Security Control Types for Third Party Service and Product Providers.” Be sure to read Paul’s other four mistakes here."
To be honest, we wouldn't really call this a mistake. According to our Open Source Development Survey, only 40% of developers indicate that tracking and resolving vulnerabilities fall under their responsibility. But we know from Heartbleed and other recently publicized vulnerabilities that this must be a shared job between application development and security, making it the responsibility of all. At Sonatype, we recognize the pressures put on developers to deliver which is why, core to our belief and product line is the integration of security, license and quality risk right into the tools developers use today. Being able to address this risk at the start of development helps ensure developers deliver trusted production applications. But we know, components age like milk and not wine so ensuring continuous monitoring for new vulnerabilities is just as important.
Having insight into potential security and licensing risks, starts by monitoring the components in your repositories. Our Nexus users, are able to use the repository health check feature to review popularity, license type and security vulnerabilities for every component in the repository. Today we see over 32,000 repository health checks run every day by our Nexus users. With the right tools and increased visibility (thank you Paul) we can ensure all developers and security professionals strive to create a secure software supply chain that includes trusted 3rd party and open source components.
