Quick Start Guide
Step 1: Onboarding Wizard
Our onboarding wizard is designed to guide you through the initial setup. By following the steps, you will:
Generate an access token for Seal Artifacts Server: This token is required to authenticate and securely access our artifact repository.
Connect Seal to your source control (optional): This step allows you to integrate Seal with your existing source code management system, enabling seamless scanning and analysis of your repositories.
Step 2: Discovering Vulnerable Packages
Before you can fix anything, you need to understand your current vulnerabilities. Seal provides three methods to discover which packages are in use and if they contain vulnerabilities.
Option 1: Connect to Your Source Control Platform 💻
This is the recommended and most automated method. If you use GitHub, GitLab, or Azure DevOps, you can connect the Seal platform directly to your repositories.
How it works: Seal's application will automatically scan your project dependencies and identify all vulnerable packages.
Pros: This method provides comprehensive and continuous scanning without requiring manual intervention.
Option 2: Use the Seal CLI in Your CI Pipeline 🛠️
If you do not use one of the supported source control platforms or prefer not to grant Seal read permissions to your repositories, you can use the Seal CLI.
How it works: Run the Seal CLI as a step in your CI pipeline. The CLI will scan your dependencies and send the results to the Seal server.
Pros: This option gives you full control over when and where scans occur, and it does not require repository read access.
Option 3: Configure Seal as Your Artifact Server 📦
This method provides a more limited view of your vulnerabilities but can be useful for certain workflows.
How it works: Configure Seal to act as your artifact server. With this setup, Seal will only have visibility into the vulnerable packages you attempt to download.
Consideration: This method may provide an incomplete list of vulnerabilities, as it only scans packages that are actively being pulled and does not account for those already in a local cache.
Step 3: Set Up Your Sealing Deployment
Once you have identified your vulnerable packages, you are ready to configure how you will deploy the fixes. There are several deployment methods, with the recommended approach being to integrate the Seal CLI into your CI pipeline.
Recommended: Use the Seal CLI in Your CI Pipeline
This is the most powerful and automated method for sealing vulnerabilities. The Seal CLI will replace vulnerable packages with sealed versions based on your defined rules.
Here are your three options for managing these rules:
Option A: Automatic Remediation
This is the simplest way to get started with automated fixes.
How it works: The Seal CLI, integrated as a step in your CI pipeline, will automatically remediate all discovered vulnerabilities without the need for any user intervention.
Best for: Teams who want a "fix everything" approach and prefer a hands-off deployment.
Option B: Remote Configuration
This option gives you centralized control over which packages are remediated.
How it works: You define your sealing rules on the Seal server. The Seal CLI will fetch these rules from the server during the CI pipeline run and apply them.
Best for: Centralized management of remediation rules across multiple projects.
Option C: Local Configuration
This option allows for fine-grained, project-specific control over remediation, while keeping the control with the developers.
How it works: You define your sealing rules in a configuration file (e.g.,
seal-config.yaml) that is stored directly in your source control repository.Pros: This allows for project-specific rules and makes it easy to track changes to your remediation strategy. You can even use automatic pull requests to update this file as needed.
Alternative: Configure Seal as Your Artifact Server
This method is less automated and requires manual intervention but may fit specific workflows.
How it works: You configure Seal to act as your artifact server. Once a vulnerable package is discovered, you must manually edit your project's dependency files to pull the sealed version from the server.
Note: This is a manual process and is not recommended for continuous, automated security.
Last updated