FOUR-STEP PRODUCT WALKTHROUGH
Catch the risky package.
Keep the work moving.
Watch a recorded policy evaluation, then explore how the same decision fits into a coding-agent and GitHub workflow.
Two ways to explore: a real recorded npm evaluation and a separate illustrative Java/GitHub walkthrough. No login or source upload.
RECORDED PRODUCT DEMO
A dependency decision, on screen.
Watch ossfind evaluate two exact npm releases against its configured policy, then check the same changes with its local pull-request dependency gate.
Silent recording with optional captions and a transcript. Recorded 17 September 2026 with live npm and OSV evidence in an isolated local pilot service. The result covers the named direct dependency and policy at recording time; it does not certify every dependency or future release.
Read the video transcript
0:00 One dependency, two decisions. This is a recording of ossfind evaluating exact npm versions with live supplier evidence.
0:03 The evaluator enters minimist 1.2.0 and requests a policy decision.
0:08 ossfind records DENY. A critical known advisory breaches the configured policy; registry and OSV evidence are verified.
0:12 The evaluator replaces the version with minimist 1.2.8 and checks again.
0:15 ossfind records ALLOW for the new exact release under the same policy. No direct advisories were returned for this version at recording time.
0:19 Actual local gate output: a committed change introducing minimist 1.2.0 is blocked, with exit status 2.
0:24 The revised committed change to minimist 1.2.8 passes the local gate, with exit status 0.
0:29 These decisions cover the selected direct dependency and policy at recording time, not transitive dependencies or a security certification.
Step 1 of 4 · Agent request
01 / BEFORE INSTALLATION
The assistant asks before it adds a package.
A developer asks for logging in a Java service. The coding assistant proposes an exact Maven version and calls ossfind before changing the project file.
Why this saves time: The team can reject a problem package before writing code around it or waiting for a later security scan.
evaluate_component({
ecosystem: "maven",
name: "org.apache.logging.log4j:log4j-core",
version: "2.14.1"
})Configured MCP clients can include Copilot, Claude Code and Codex. The GitHub gate checks supported pull-request changes even when an agent skips this call.
02 / EARLY POLICY CHECK
A known advisory triggers a deny.
ossfind compares the exact release’s license and known advisories with the organization’s rules. In this example, a critical advisory breaches the sample policy. The assistant should try another exact version and evaluate it again.
Outcomes are explicit: allow, review or deny. Missing evidence leads to review; an allow is not a safety certification.
- Package
- log4j-core · 2.14.1
- Policy rule
- Critical known advisory → deny
- Evidence
- GHSA-jfh8-c2jp-5v3q ↗ · OSV
- Next step
- Evaluate another exact version
The advisory is real; this receipt and its policy rule are illustrative. A live result uses current evidence and your configured policy.
03 / SECOND CHECKPOINT
The pull request catches a skipped check.
If the rejected version is committed anyway, the GitHub gate evaluates the supported direct-dependency change against the same policy. In block mode, its failed check can be required before merge.
Start gently: Run the gate in observe mode, tune policy and supported inputs, then require a blocking check.
DENY · Critical known advisory under the sample policy. Replace the version, evaluate the exact replacement, and rerun the gate.
The gate currently covers specific npm lockfiles, exact Python requirements and direct Maven POM versions. It is not a full repository scan.
04 / REMEDIATION AND HISTORY
An approved change can move forward.
The assistant or developer selects another exact version and asks ossfind again. If that version satisfies the current policy, the revised pull request can pass its required check. The decision trail remains available for security review.
The payoff: Developers get a concrete next step, while AppSec can see the rejected attempt, the re-evaluation and the policy used.
- 1Original release deniedlog4j-core 2.14.1 · advisory evidence retained
- 2Replacement version evaluatedExact alternative receives allow under this example policy
- 3GitHub check passesRevised direct dependency can proceed to normal review
The replacement is intentionally unnamed: teams must verify a specific release against their own policy and current evidence. Real audit records include the actor, evidence time and policy fingerprint.
TRY THIS WITH YOUR TEAM
Bring one dependency your scanner rejected.
Pamyn can configure one policy, one supported ecosystem and one repository for a focused pilot, then compare early decisions with your existing review process.
Four-week assisted pilot: US$249, subject to agreed scope and applicable taxes. No production access is needed for a discovery call.