Choosing Your Deployment Method
The Seal platform is designed to adapt to your organization's unique processes. The most critical factor in choosing your deployment method is deciding on the desired level of automation and the distribution of responsibility between your security and development teams.
Recommended Workflow: CLI Integration
For the smoothest, most automated, and most efficient experience, we highly recommend integrating the Seal CLI directly into your CI pipeline. This approach eliminates the need for manual dependency changes and unlocks the three automated Sealing Methodologies.
CLI Integration Deployments (High Automation)
These deployments require the Seal CLI to be integrated into your CI/CD pipeline. The CLI is responsible for cleanly and automatically applying security fixes as configured.
This is the fully automated deployment model, offering the fastest time-to-fix for newly disclosed vulnerabilities.
Workflow: Vulnerable packages are automatically replaced with their sealed versions whenever the CI runs. No manual interference or configuration changes from developers or the security team are typically needed.
Control & Responsibility: Provides the highest level of automation, guaranteeing your application is always up-to-date with the latest patches. All that's required is deploying the sealed version to production.
This model provides high automation while keeping the security team fully in control of which fixes are applied.
Workflow: Vulnerable packages are sealed according to remediation rules set by the Security Team through Seal's centralized web interface. The fixes are applied by the CLI during the build.
Control & Responsibility: The Security Team defines the rules and can fix vulnerabilities independently from the developers. Critically, there is no Pull Request (PR) created, and the changes are not tracked in the source control's commit history, streamlining the security patch process.
This deployment integrates sealing directly into the standard developer workflow, ensuring full source control visibility and developer sign-off.
Workflow: Vulnerable packages are sealed based on remediation rules defined by Developers in each project’s local configuration file.
Control & Responsibility: Developers have control over what is sealed. Every update to the local configuration file requires a Pull Request (PR) and a commit to the source control, ensuring full auditability. Note: The Seal App can be connected to your source control to automatically create these PRs instead of requiring developers to create them manually.
2. Artifact Server Deployment (Manual)
This option provides maximum developer control without requiring the integration of the Seal CLI into your CI pipeline.
Configuration: For this method, you must configure Seal as your artifact server for dependency resolution, or as an additional remote of your existing artifact server.
Workflow: When a vulnerability is remediated, developers are responsible for manually editing the project's dependency manifest (e.g.,
package.json,pom.xml) to explicitly reference the sealed package version.Control & Responsibility: This gives the developers full control over version selection. However, it requires the most effort and can be technically challenging when dealing with updating transitive dependencies (dependencies of your dependencies) in some package managers.
Summary table: Deployment Comparison
CI Integration
Required
Required
Required
Not required
Control Owner
Security Team
Security Team
Developers
Developers
Sealing Rules
Automated
Centralized,
on Seal Server
Local configuration file
Manual dependency file edits
Developer Effort
None
None
Moderate (PR Review / Merge)
Highest (Manual dependency edits)
Key Benefit
Maximum automation and speed
Centralized security control & speed
Developer sign-off & audit trail
No CI integration required
Last updated