Now that 2024 is really in full swing, it’s amazing to me to think about where the Oligo product team was one year ago: in stealth, unable to reveal publicly the incredible things that the Oligo Platform was capable of … or our vision for the future.
We’ve been releasing big features so fast that sometimes it’s hard to stop and catch our breath – but we also want to make sure the whole world knows about how we’ve been working to solve the biggest problems in security today.
So here’s a wrap-up of the best Oligo features of 2023 – and since it’s hard to keep it inside, I’ll share something about where we’re headed next (it’s even more exciting).
Feature #1: Exploitability & vulnerable function reporting
It’s not enough to know whether a CVE is present in your application – more often than not, they can’t be exploited, and aren’t high-priority regardless of their severity score or any known exploits. At Oligo, we built function-level exploitability detection that finds every exploitable vulnerability in all of your application code – for all the applications you make and the ones you run.
This feature gives you clear proof that a vulnerability is actually exploitable, with root cause analysis. It’s not “noise reduction” – it’s proving exactly which vulnerabilities create risk, and how.
What we love about it: It’s easy for developers and security to see each other as adversaries instead of allies – no one likes having their time wasted, and when security tools tell developers to fix vulnerabilities without proving exploitability, that’s exactly what happens.
The Oligo sensor looks deeper to detect whether a vulnerable library is executed and whether the specific vulnerable function is running. If the function itself never runs in your application, it’s not exploitable. We give your teams proof, showing how non-exploitability was determined (was the library not executed? Is the vulnerable function never called?) Once the Oligo sensor tracks down which vulnerabilities are actually in libraries that are actually executed, indicating they can be exploited, we prioritize further based on CVSS, EPSS, CISA’s KEV, and exploit maturity to help your teams understand which fixes are most urgent.
Feature #2: Image to Repo
Container security products on the market today see containers as an opaque box: even if they can tell something has gone wrong inside, understanding the details is difficult. But to actually fix exploitable vulnerabilities – or those being actively exploited in production – takes tracking down the vulnerable repository, not just identifying the impacted application.
That’s why we created our Image to Repo feature, which traces vulnerabilities from the container images where they’re initially detected by the Oligo sensor back to their source repository.
What we love about it: Now, if you find any of your applications have an exploitable vulnerability (or that you’re actively being exploited!), you can instantly identify exactly which repository needs prompt attention to reduce your risk – and which developer the security team needs to talk to in order to get the vulnerability remediated.
Feature #3: Malicious Package Detection
Malicious packages (open source libraries with embedded malware) can resemble known packages well enough to fool developers and automated package manager software. Unlike vulnerable packages, which can exist in code for months or years without being exploited, malicious packages are an immediate security threat.
Now, Oligo can detect malicious packages when they are present in any of your applications, including your transitive dependencies.
What we love about it: Because Oligo can be used not only on your first-party apps but also third-party, you can immediately detect when malicious packages are present in vendor applications – so these vendors can be immediately notified and you can take steps to prevent the malicious package from impacting your systems.
Feature #4: Policies & Issues
No one wants to handle their security findings totally manually. When specific types of security risks are found, specific people need to be notified – and no one needs another notification tool.
This is why it was important for us to develop our Policies & Issues features, which allow you to set a wide range of customizable policies, which will automatically create issues in Jira and alert necessary stakeholders.
What we love about it: Different organizations have different risk tolerances – and the risk can be significantly different from one application to another. With full control over what triggers alerts, you can fine tune Oligo to fit your organization’s needs.
Feature #5: Dynamic SBOM & VEX
When businesses started creating SBOMs, they soon found they weren’t as useful as they hoped – they didn’t contain any way for organizations to show changes in their product, or any way to indicate that specific vulnerabilities were not exploitable in the application, even if the code base contained a vulnerable library.
Enter VEX: Short for “Vulnerability Exploitability eXchange,” this companion artifact to an SBOM shows an analysis of exploitability to help customers and compliance experts understand the real risk in an application. But while VEX seems like a great idea (especially in a world where 80% or more of the vulnerabilities present in application libraries aren’t exploitable), organizations have had to create them manually, which requires tremendous effort.
That’s why we’re so proud of our Automated VEX and Dynamic SBOM features, which take the manual work out of creating VEX artifacts and help you see exactly what libraries and functions are running and executed in your application code.
With dozens of new vulnerabilities disclosed daily, manually created VEX artifacts are out of date the moment they’re created. Automation is the only way to keep VEX up-to-date and available immediately upon request by customers or other stakeholders.
What we love about it: Using third-party applications and not sure what’s in them? No need to ask the vendor for an SBOM or VEX – use Oligo to get them automatically.
What’s the worst part of application-layer attacks? To me, it’s that cyber criminals keep getting away with them, and that we’re always left picking up the pieces after the burglar has already left the building, holding the bags of money.
All the tools we have to see our containers and applications leave us blind to what’s happening in real-time – everything is done in hindsight, where we all have perfect vision and can say “ah, now it’s so obvious how this could happen, but how could we have known?”
Well … get ready to change everything you knew about when it’s possible to detect an application-layer attack.
What if you could detect an attack on your applications the moment a breach began – before any lateral movement occurred, before any damage was done?
What if you could have that instant detection even for attacks on vulnerabilities that haven’t been assigned a CVE … either because they haven’t yet been assigned one, or because they stem from a bad configuration or other non-CVE issue?
And what if you could have that kind of protection for every application you use, not just the ones you developed?
That’s not security science fiction. It’s what we’ve got working right now in our labs – and what we’ll be bringing to you later this Q1.
Until then … keep your eye on this space. And if you would like a little more in-depth sneak peek of what we’re working on, we’d be happy to show it in action – book a live demo to learn more.