Hackers are getting out of hand. We’re sure you’ve noticed. Ignoring self-owns like the recent CrowdStrike debacle making the news, we seem to hear about new zero-day, zero-click exploits on a daily basis. Software infrastructure is complex and this complexity makes it vulnerable to bad actors.
What can you do when your business is built on a technology platform constructed from thousands of open source and third party libraries containing millions of lines of code that your team didn’t write?
And what can you do when every new service you launch, like the API gateway your app and website will talk to, is discovered and scanned for vulnerabilities within an hour of going live? And not just once, but continuously by automated tools run by multiple anonymous parties?
Keeping your platform secure sounds daunting when spelled out like that.
But there is a way forward, and it involves integrating threat intelligence into your development process from the very beginning. Before your developers write the first line of code, and before they start installing the libraries your technology platform is going to be built on.
Threat intelligence is applying knowledge of the tools and techniques bad actors use to breach security. It can be used at every point in the architecture and lifecycle of your platform. This makes it a huge topic and one that keeps shifting as new techniques and counter-measures are put into play.
It’s too huge a topic for a single article, so we’re just going to look at the first step – building your platform – and only one facet of that: vetting open source and third party code.
We’re going to give you an overview of the easiest to use tools available for incorporating this essential process.
But first we’re going to talk about the OWASP Top Ten and where this vetting of code sits on the list.
The OWASP Top Ten and secure coding practices
The OWASP Top Ten is a list of the 10 most critical security risks to web applications. It’s compiled by OWASP (the Open Worldwide Application Security Project – a nonprofit foundation) in consultation with its membership of cybersecurity professionals.
The OWASP Top Ten list is due to be updated in early 2025, but here are the risks from the current 2021 version of the list:
We’re discussing “web applications” throughout this article because current practices are to build a web-based backend that both apps and websites frontends talk to on behalf of users. OWASP also has security recommendations for mobile apps you can read here, but we’re not going to talk about that in this article.
As we said earlier, this article is going to focus on just one item from the OWASP Top Ten – “Vulnerable and Outdated Components”. And we are going to focus on this security risk because there are services that can help you manage it. They’re not “set and forget”, but they don’t require in-depth training or expertise in order to adopt them and get immediate benefit from them.
They augment the role of the “Software Security Engineer” and automate the process of researching vulnerabilities that used to be done by googling or searching through the NIST National Vulnerability Database (NVD).
Some services, like Snyk, have their own security researchers to discover vulnerabilities and develop mitigations for them (like patches or updates for the troublesome library) and also contribute those vulnerabilities back to the NVD.
Snyk
Snyk call themselves “The developer security company” and they offer a suite of tools and services for mitigating supply chain attacks.
These tools include Snyk Open Source. This performs source code analysis to find vulnerable dependencies. It integrates with your developers’ IDE, can scan pull requests, and can be integrated into your CI/CD pipeline to check no new vulnerabilities make it into production.
They also provide continuous monitoring so if new vulnerabilities are discovered you can move quickly to address them.
Snyk can be used for free by individual developers and small teams, with some limitations on testing and with no Jira integration.
GitHub
If you’re already using GitHub for hosting your code or planning to, it makes sense to take advantage of its built-in security features. GitHub’s Dependabot automatically scans your dependencies for vulnerabilities and raises pull requests to update them, similar to Snyk’s open-source scanning, but without the need for additional setup.
GitHub Advanced Security goes further with features like secret scanning and code scanning, catching issues early, even before code is pushed. While Snyk also offers these kinds of tools, GitHub’s advantage is that everything is built right into the platform you’re already using for version control.
GitLab
GitLab, GitHub’s open-source competitor, also offers a suite of security features designed to fit smoothly into your development pipeline. If you’re already using GitLab for CI/CD or planning to, its built-in security tools can save you time and effort by automatically integrating into your workflows.
Like Snyk, GitLab includes dependency scanning, checking your code for vulnerabilities in open-source libraries and suggesting fixes with merge requests. GitLab also offers security features like container scanning, static application security testing (SAST), and dynamic application security testing (DAST), all built into the platform. This gives it an edge for teams already leveraging GitLab’s DevOps capabilities, as you get a unified toolset for both development and security without needing to add third-party integrations.
There are 65 different service providers for this kind of service (Software Composition Analysis) on G2. Way too many to go through without wasting your time, but between Snyk, Github, and GitLab you have three options your developers can try integrating into your development process today.
Trust but verify the libraries you rely on
We’re all building on the shoulders of giants out here. Not-invented-here syndrome needs to give way to the demands of time-to-market, which means open source libraries, which includes entire ecosystems like React, Node, and Laravel as well as server operating systems (Linux), web servers, and the proliferation of databases.
You are going to use third party code so make the decision now to mitigate the risks of bad actors, bad design decisions, and changing technology that necessity will expose you to.
Get your developers on board with one of the options we’ve talked about, or go spend a couple weeks talking to each of the vendors on G2’s list, Just make sure you have a solution in place before you start running code.
