Last summer, we announced our plan to expand our partnership with Trend Micro to provide security operations teams visibility and tracking of vulnerabilities and license risks in open source components. The long-standing partnership already includes container image security scanning that leverages Snyk’s proprietary vulnerability database.

Open source helps developers build faster. But who’s making sure these open source dependencies (sometimes years out of development) stay secure? In a recent npm security research activity, Snyk uncovered a total of 8 npm packages which matched a specific malicious code vector of attack. This specific attack vector of the malicious packages included packages which had pre/post install scripts, which allowed them to run arbitrary commands when installed.

We are happy to announce Snyk Open Source support for GitHub Security Code Scanning, enabling you to automatically scan your open source dependencies for security vulnerabilities and license issues, as well as view results directly from within GitHub’s Security tab! A key ingredient of Snyk’s developer-first approach is integrating Snyk’s security data into the exact same processes that developers are using, whether this is within a developer’s IDE or a Git-based workflow.

Spencer Pearlman, Security Researcher at Detectify, presented A Hacker’s Approach to Finding Security Bugs in Open Source Software in a partnered webinar with friends at Debricked. Securing modern web applications takes new approaches, and this includes looking at it from a hacker’s perspective. Here are highlights from the presentation on how tech teams can apply the same hacker mindset to discover vulnerabilities in open-source software in their tech stack.

Many of the third-party components we find in audits have been pulled in their entirety from public software repositories (with GitHub being the most popular these days). But with some frequency we also come across snippets—lines of code that have been copied and pasted into source code. They might be a piece of a GitHub project, but they may also have been taken from a blog site like Stack Overflow or CodeGuru.

The number of open source vulnerabilities discovered each year never seems to stop growing, emphasizing the importance of developers addressing them quickly and efficiently. However, simply identifying vulnerabilities is insufficient; their sheer scale makes it necessary to have an intelligent way of understanding which ones need to be fixed first to decrease the risk of a breach. For development teams in this environment, remediation prioritization and broad vulnerability coverage are critical.

The recent SolarWinds breach highlights a new paradigm in the Software Supply Chain. When compared simply to the code itself without any additional tools, Proprietary Code is no more secure than Open Source. By contrast, many would argue that Open Source Code is more secure due to a faster fix/patch/update cycle and the pervasive access to source code (Clarke, Dorwin, and Nash, n.d.).

Whether you’re a developer or a security engineer, Software Composition Analysis—or SCA for short—is a term you will start to hear of more and more. If you haven’t already, that is. The reason for this is simple. Your company is increasingly relying on open source software and containers to develop its applications and by doing so is introducing risk in the form of security vulnerabilities and license violations.