Remote Configuration
Remote Configuration provides a highly automated deployment model that places centralized control of remediation rules directly in the hands of the Security Team via the Seal server. This method allows the security team to fix vulnerabilities across the organization's codebase independently of the development lifecycle.
How It Works
With this configuration, remediation is managed entirely from the Seal web interface, without developers needing to adjust local configuration files.
Rule Creation: The Security Team defines a remediation rule on the Seal server using the web interface (e.g., "globally seal all instances of
[email protected]").CLI Execution: The Seal CLI, integrated into the CI pipeline (immediately after package installation, e.g.,
npm install), pulls these rules directly from the Seal server.Automatic Substitution: The CLI performs the substitution during the build, replacing vulnerable packages with their sealed versions according to the remote rules.
No Source Code Change: The fix is applied by the CLI during the build, meaning no Pull Requests (PRs) are created and no modifications are made to the project's source code dependency files (
package.json,requirements.txt).
Key Benefits
Centralized Security Control: The Security Team controls what gets sealed and when, operating independently from the development team's sprint schedule.
Fast, Clean Fixes: Fixes are applied automatically by the CLI, ensuring clean application without manual source control tracking, streamlining the patch process.
Decoupled Workflow: The security remediation process is decoupled from the developer's typical source control workflow, preventing potential disruption.
Configuration
To use Remote Configuration, follow the instructions in how to integrate the Seal CLI as a step in your CI pipeline.
Sealing a Package (Creating a Sealing Rule)
To define a new rule, access the Protection screen in the web interface:
Click the Seal button next to the vulnerable package alert.
In the Sealing Instructions dialog, use the Remote tab to define the rule.
Choose the scope: a Local Rule for the current project only, or a Global Rule for all projects across the organization.
In the Sealing instructions dialog under the Remote tab you will be able to define a new rule for this package. A local rule will apply only for this projectt, whereas a global rule will apply for all projects.
Once you create a rule sealing the package the vulnerable package will have the green Sealed marking where the Seal button was before (see the first screenshot).
The sealed versions are made to be fully-compatible with the vulnerable ones, so other than fixing the vulnerability there are no side-effects to the substitution. The next time your CI pipeline runs it will incorporate the remediated version instead of the vulnerable one.
Unsealing a package
To unseal a package, click on the "..." next to the sealed package's row, and click Unseal package.
In the dialog that pops up you'll be able to delete the rule that sealed this package.
Note that in principle it's possible that more than one rule defines that a certain package will be sealed. For example, you may first have defined to fix [email protected] in a particular project. Then, after encountering the same vulnerable package in a different project, you may have defined the a global rule fixing all instances of [email protected]. This means that there are actually two distinct rules that specify that [email protected] from the first project must be remediated. If that is the situation, you will see more than one rule in the unseal dialog, and you will be able to select if and what rules to delete.
Last updated