Components represent a functional piece of your software, like a frontend, backend, or microservice. Components typically come from a single code repo or a subdirectory of a monorepo and represent a stream of SBOMs produced by your build pipeline.
When making a single Pull Request, the EdgeBit bot will detect changes to multiple components and deliver context about your changes, taking into account your settings and the real-time history of each component.
Components have the following properties:
Labels
Used for organization, reporting and aggregation.
Source Repository
Code repository where the component is built from.
Security Remediation SLAs
Number of days your organization targets to fix security vulnerabilities. Useful when different teams or apps have different risk profiles.
Machine Label Query
Set of labels that indicate deployment of the component on your server fleet. Useful to ignore testing environments or to only select production machines.
Vulnerability Suppressions
Automatic (by EdgeBit) or manual (by you) indications that a security vulnerability is rated differently for this component.
A Component doesn’t have a version itself. The SBOMs attached to the component each represent a specific version of your application and are tagged to identify them. Conceptually this works the same as container tags.
Inside of your build pipeline, you might tag your newest release with v1.2.3 and latest.
It’s useful for latest to be used as a floating tag that represents the newest SBOM on main or the newest version deployed to production.
$ ebctl upload-sbom \
--component frontend \
--tag latest \
--tag v1.2.3 \
--commit $LATEST_SHA \
--image-tag $IMAGE \
--repo https://github.com/example/projectname \
frontend.spdx
The stream is useful to understand if a security issue is fixed but not deployed yet, or inventory the set of versions currently deployed across regions/zones.
Each component has a unique set of detected vulnerabilities found in the stream of SBOMs and unique set of active/dormant dependencies that influences the priority of those vulnerabilities.
Each vulnerability is tracked from first observation to calculate the SLA for fixing it. SLA targets are set per EdgeBit Project and you may refrain from having an SLA target for a severity level to avoid tracking it.
Suppressions or modifications to the severity of a vulnerability are unqiue to the component, in order to accurately represent the risk when dependencies are used differently by teams in your organization.
The severity of a vulnerability can change at any time. The common causes are:
SLA targets are re-calculated any time this happens. When dependency transitions from dormant to active, the transition timestamp is used to calculate the SLA. For all other circumstances, the first observation timestamp is used. First observation is the timestamp when the SBOM is tagged with the default tag (eg. latest) or when the SBOM is found running on your fleet.
EdgeBit can automatically deprioritize vulnerabilities attached to dormant dependencies in your application, based on your preferences per component.
Drop 1 or 2 severity levels
Engineers can opt to drop 1 or 2 of severity levels. In practice, this means a High vulnerability within a dormant dependency could drop 1 level from High→Medium to reflect the reduced risk it poses.
Always Suppress to Medium or Low
Engineers may opt to always drop dormant dependencies to a certain severity to reflect the risk to the application.
Disabled
Automatic suppressions can be disabled entirely. Manual suppressions are still allowed.
Manual suppressions can always be applied to specific vulnerabilities to reflect investigation into their risk and threat to the application.
Components understand where they are deployed in your server fleet through the EdgeBit Linux agent. Configure a Machine Label Query to control which machines are used to determine this inventory and the active/dormant status of dependencies.
Machines are automatically labeled with certain metadata when it is available:
EdgeBit automatically creates a bundle of the latest artifacts for each component. These files fulfill compliance regulations for supply chain security.
| Name | Description | Source | Frequency |
|---|---|---|---|
| SBOM | Software Bill of Materials | Your build pipeline | on build |
| VEX | Vulnerability Exploitability Exchange | Real-time usage on your servers | continuous |
