# Your first Proof of Value A Proof of Value (PoV) is a structured evaluation of Seal against your own codebase, run jointly with Seal's sales engineering team. It is not a self-service trial. By the end, you should be confident that Seal can remediate the open-source vulnerabilities in your stack without breaking your components, and you should have a working plan for how to deploy Seal in production. A typical PoV runs 2-3 weeks. A Seal sales engineer is available throughout: scoping the work with you, building the sealed packages you ask for, and helping you over any rough spots in integration. ## What a successful PoV produces You leave the PoV with two things: * **Confidence that Seal works on your code.** Sealed versions of packages from your environment, dropped into your build, with the component still passing your tests. * **A deployment plan.** A concrete idea of which deployment method (Remote, Local, Artifact Server, Manual) you will adopt, where it sits in your CI/CD, and what rollout looks like after the PoV. ## Picking a component The PoV runs against a single component from your environment, sometimes two. Pick something: * **Representative of your real stack.** If most of your build pipeline is Java with Maven, a Java/Maven service is the right pick. Choosing the one Python tool nobody owns will not tell you what you need to know. * **Vulnerable.** The component should have known open-source vulnerabilities, ideally including some high or critical severity. Without vulnerabilities to remediate, there is nothing for Seal to demonstrate. * **Buildable and testable by you.** You need to be able to rebuild the component with the sealed packages in place, and you need to be able to verify it still works (functional tests, integration tests, a manual smoke test, whatever you trust). Enterprises ship many components in many ecosystems, and producing sealed versions for all of them up front is not the point of a PoV. One representative component is enough to prove the mechanics. If your environment has two genuinely distinct surfaces (for example, a Maven backend and an npm frontend) and one is not representative of the other, picking one component from each is reasonable. More than that is usually unproductive. ## The steps ### 1. Kickoff with sales engineering A Seal sales engineer walks through your setup with you: which ecosystems you use, where your build pipelines live, which vulnerability scanners you run, and what your remediation workflow looks like today. Out of that conversation, you agree on: * The component you will use as the PoV target. * The deployment method that fits your environment best (typically Remote or Local mode of the Seal CLI). * Who on your side runs the integration: usually a developer or a DevOps engineer. ### 2. Send the package list Once the component is chosen, send Seal a list of the vulnerable open-source packages it depends on, with **exact package names and exact versions**. The version is essential. Seal builds a sealed version from a specific origin version, not from a range. `requests@2.28.1` and `requests@2.31.0` are two separate origin versions and produce two separate sealed versions; Seal needs to know which one your component actually pulls in. The list usually comes from your existing scanner: a CSV export from Snyk, the dependency tree from `mvn dependency:tree`, the lockfile from `package-lock.json`, or a similar artifact. Whatever format it arrives in, the names and versions need to be unambiguous. ### 3. Seal builds the sealed packages From your list, Seal selects 3-5 packages that exemplify your remediation needs (high and critical CVEs, mainstream packages, a representative spread across ecosystems if relevant) and produces sealed versions for them. The sealed packages land on the Seal Artifact Server, ready for your build to pull. The sealed versions do not appear on the Protection page's Sealed packages tab right away. They show up there only after your build (or a manual download) actually pulls each sealed package at least once. Until then, you can still: * Create a Sealing Rule against the new sealed version, so the next CLI run replaces the vulnerable origin version with it. * Pull the sealed package directly from the Seal Artifact Server in artifact-server deployments. * Download the sealed artifact manually from the Repository page and drop it into your build by hand. ### 4. Integrate the sealed packages into your build There are two paths for getting the sealed packages into your component. **Recommended: a separate dev pipeline.** Run the Seal CLI in a dev or feature-branch CI pipeline, configured to replace the vulnerable packages with their sealed counterparts. This is what the integration will look like in production, so testing it at PoV time gives you a directly applicable result. **Fallback: manual replacement.** If standing up a dev pipeline is impractical at PoV time (vendor onboarding delays, security review, no DevOps capacity, or the component is built in a way that does not lend itself to a separate pipeline), the developer can replace the packages manually. Pull each sealed version from the Seal Artifact Server or download it from the Seal UI, swap it into the build, and rebuild. This requires more developer time and does not validate the production integration, but it does prove that the sealed packages work. Your sales engineer will help you pick the right path and unblock you if integration runs into trouble. ### 5. Build and test Rebuild the component with the sealed packages in place, and run whatever validation you would normally run before shipping. The goal is to confirm two things: * The build succeeds. * The component behaves the same as it did with the original packages. If something fails, your sales engineer is the first call. Most issues at this stage are integration-level (a misconfigured CLI invocation, a manifest the Seal CLI did not pick up, a registry-routing problem) rather than problems with the sealed packages themselves. ### 6. Review against success criteria With the rebuild green, walk through the [success criteria](#what-a-successful-pov-produces) above with your sales engineer. If both hold, the PoV is successful and the conversation moves to deployment planning. ## Timeline expectations The clock on a PoV starts when you send Seal the package list and stops when you finish testing the rebuilt component. That window is typically 2-3 weeks. Most of it is on your side: integrating in a dev pipeline (or finding a developer with time to do the manual swap) and running tests. Seal's package builds typically take a few days from list to delivery. ## Related * [The onboarding wizard](/new-documentation/new-docs/onboarding-wizard.md): how a tenant is set up at the start of a PoV. * [Creating a Seal Project](/new-documentation/new-docs/creating-a-seal-project.md): the Seal Project that holds the PoV component's scan data. * [Architecture overview](/new-documentation/new-docs/architecture.md): the components that show up in the integration step. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sealsecurity.io/new-documentation/new-docs/proof-of-value.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.