OSS should be safe to use.
Simplify OSS selection
Endor Labs collects and analyzes a large amount of information about open source and customer packages and uses it to compute the Endor Score, a high-level, easy-to-understand metric of how well a package does based on factors such as security, activity, popularity, and code quality. With this score you can improve OSS selection through two methods:
- Pre-merge checks: Set policies that prevent risky dependencies from being merged into your projects.
- AI-assisted OSS selection: Developers can ask DroidGPT for alternatives to risky projects, with responses scored based on project health.
OWASP Open Source Top 10
The OWASP Open Source Software Top 10 addresses risks that come with using OSS. Vulnerability detection (and sometimes license risks) is where most SCA tools stop but with Endor Labs, you can implement an OSS security program around the list through policy-driven automation that includes:
- Vulnerabilities: Known vulnerabilities associated with a software component.
- Operational Risks: Issues that may make it more expensive to address any application impacting bug, including a security vulnerability.
- License Risk: Issues that may cause legal or compliance risk associated with your software.
SCA shouldn't waste your time.
Eliminate false negatives
Reduce SCA noise by 80%+
Because most SCA tools can't determine which open source dependencies are in use, they produce false positives: Alerts for every potential dependency with a vulnerability. By using source code as the ground truth and applying program analysis techniques, Endor Labs can pinpoint every direct and transitive dependency in use, down to the functions being called by your application. In addition to producing a highly-accurate map of your dependencies, program analysis enables "reachability-based SCA", so you can quickly de-prioritize the noise based on whether the vulnerable function is reachable.
Learn more in Why Your SCA is Always Wrong.
Compliance should improve security.
Achieve software transparency with SBOMs
Although SBOMs are increasingly becoming required for compliance reasons, in practice most organizations request SBOMs to evaluate the potential risk of a vendor or want the ability to regularly scan SBOMs for new risks. To meet these kinds of expectations, software producers must generate highly-accurate SBOMs each time an app pushes to production. And when a software consumer receives an SBOM, it's to be expected that they will review the components for vulnerabilities. This causes extra work for both producer and consumer, as the consumer has to research each vulnerability or request that the information be provided. A VEX document makes this process simpler by providing a mechanism to classify and label the vulnerabilities. When delivered alongside an SBOM, the VEX informs consumers about any vulnerabilities, including severity, whether it's exploitable, and so on.
With Endor Labs, SBOM and VEX generation can be automated. Because Endor Labs uses your source code as the source of truth, you can have confidence your SBOMs contain every direct and transitive dependency - offering no nasty surprises to your customers. Once your dependencies are mapped, you can generate SBOM and VEX documents that automatically include reachability data, and annotate whether or not an application or library is affected.