Quick Start Guide
Last updated
Last updated
The first thing we need to do is discover what vulnerable packages are currently in use.
If you're using , or , the recommended way to do that is to connect the Seal platform to your repositories. Seal's app will then scan your project dependencies and identify the vulnerable packages.
However, if you're not using one of those platforms or prefer not to give Seal read permissions to your repositories, you may instead run the Seal CLI as , and have it send the scan results home to the Seal server.
Lastly, you may . With this configuration, Seal will identify the vulnerable packages you're pulling from the server, but will have much less visibility due to caching.
The recommended setup is to integrate the pipeline. With this setup, our CLI will replace the vulnerable packages with sealed ones, in accordance with preset instructions. These instructions can be saved in a file committed to your source control, or on the Seal server. To quickly run an example on your machine without configuring your CI see the usage examples.
However, if you prefer not to use our CLI as part of your CI, you may instead configure , and then edit your dependencies manually.
After you set up your sealing deployment, you will want to replace your vulnerable packages with their sealed versions.
If you're using the Seal CLI as part of your CI you have :
Use automatic remediation and automatically fix everything.
Use rules to decide which packages are remediated and how.
Use automatic pull requests generated by Seal's GitHub, GitLab or Azure DevOps app.
Manually edit (or use the Seal CLI to edit) a project's Seal configuration file and manually create a pull request.
If you're not using the Seal CLI as part of your CI then to seal a package you must , and then manually edit your dependencies to use the sealed version.