SCA Integrations

When Seal Security releases a remediated version, the version string is usually the original version with some suffix, usually -sp1 or +sp1. For example, ejs@2.7.4 would become ejs@2.7.4-sp1.

Different SCA tools treat these versions differently. Some scanners no longer show the vulnerability alerts for these versions, while some continue to recognize these versions as affected. For some scanners the behavior is actually ecosystem specific.

To avoid the false positives the Seal CLI integrates with various SCA tools. When the integration is operative, the Seal CLI will mark the remediated vulnerabilities in the sealed package as remediated, if possible with a message saying it was remediated by Seal Security.

Vulnerabilities that were not remediated in the sealed version would continue to appear in the alerts, as will new vulnerabilities that are discovered later on and haven't been patched in the existing sealed version.

Snyk integration

There are two types of Snyk integrations -

1. Using the Snyk API - best for the Remote Configuration deployment.

2. Using the Snyk policy files - best for the Local Configuration deployment.

Snyk API integration

This integration with Snyk leverages the Snyk API.

To setup the integration just define the following environment variables:

SEAL_SNYK_URL = <Snyk server's URL> (by default "https://api.snyk.io")
SEAL_SNYK_TOKEN = <Snyk access token>
SEAL_SNYK_ORG_ID = <ID of your Snyk organization>
SEAL_SNYK_PROJECT_ID = <ID of the Snyk project that is scanned>

You can also define them in the .seal-config.yml file at the root of your project:

snyk:
  url: <Snyk server's URL> (by default "https://api.snyk.io")
  token: <Snyk access token>        
  org-id: <ID of your Snyk organization>
  project-id: <ID of the Snyk project that is scanned>

You can find or create a token to Snyk under Organization -> Settings -> Service accounts. Org Collaborator permissions are sufficient. Use an API key with no expiration as shown below:

You can find the Snyk organization ID under Organization -> Settings -> General -> Organization ID.

You can find the Snyk project ID under Organization -> Projects -> specific project -> Settings -> Project ID.

Snyk policy files integration

This integration with Snyk leverages the the .snyk policy files, typically located in the project root. Since the integration requires access to the source files, it can only be used together with the --generate-local-config flag.

To apply the integration run:

seal scan --generate-local-config --generate-snyk-policy

It will cause the Seal tool to generate or update the appropriate .snyk file, so the Snyk scanner will be notified of the vulnerabilities fixed by Seal.

Black Duck integration

The integration with Black Duck uses its API.

To setup the integration just define the following environment variables:

SEAL_BLACKDUCK_URL = <Black Duck server's URL>
SEAL_BLACKDUCK_TOKEN = <Black Duck access token>
SEAL_BLACKDUCK_PROJECT = <Name of the project on Black Duck>
SEAL_BLACKDUCK_PROJECT_VERSION_NAME = <Git branch that is scanned>

You can also define them in the .seal-config.yml file at the root of your project:

blackduck:
  url: <Black Duck server's URL>
  token: <Black Duck access token>        
  project-name: <Name of the project on Black Duck>
  project-version-name: <Git branch that is scanned>

GitHub Advanced Security & Dependabot integration

The integration with GitHub Advanced Security leverages the Dependabot API.

The token should be a PAT with repo:security_events permissions (read / write / dismiss security alerts).

To setup the integration define the following environment variables:

SEAL_DEPENDABOT_URL = <Dependabot server's URL>
SEAL_DEPENDABOT_TOKEN = <Dependabot access token>
SEAL_DEPENDABOT_OWNER = <Name of the GitHub organization>
SEAL_DEPENDABOT_REPO = <Name of the GitHub repository>

You can also define them in the .seal-config.yml file at the root of your project:

dependabot:
  url: <Optional URL for Dependabot's server, if not using public GitHub>
  token: <Dependabot access token>        
  owner: <Name of the GitHub organization>
  repo: <Name of the GitHub repository>

Note that as Dependabot creates a single alert for different vulnerable versions of the same package, if your project is afflicted by more than one vulnerable version of the same package (which is only possible in certain ecosystems), Seal will resolve the alert only if all vulnerable versions were sealed.

Ox integration

The integration with Ox leverages the Ox API.

To setup the integration define the following environment variables:

SEAL_OX_URL = "https://api.cloud.ox.security/api/apollo-gateway"
SEAL_OX_TOKEN = <Ox access token>
SEAL_OX_APPLICATION = <Name of the Ox application>
SEAL_OX_EXCLUDE_WHEN_HIGH_CRITICAL_FIXED = "true"

You can also define them in the .seal-config.yml file at the root of your project:

ox:
  url: "https://api.cloud.ox.security/api/apollo-gateway"
  token: <Ox access token>        
  application: <Name of the Ox application>
  exclude-when-high-critical-fixed: true

Note that as Ox shows a single alert for all vulnerabilities in the entire dependency stemming from a single direct dependency, alerts will not be closed until all such vulnerabilities are remediated.

However Seal will create a comment advising about which vulnerabilities were sealed therein, and will lower the priority of the alert in accordance with the most severe open vulnerability.

There's also a possible configuration for Seal to close the Ox alerts if all High and Critical vulnerabilities were sealed, as shown above SEAL_OX_EXCLUDE_WHEN_HIGH_CRITICAL_FIXED="true".