eyeprolog

Software supply-chain vulnerability response

Decision

Should checkout-prod be deployed, and if not, exactly which transitive dependency and fix are responsible?

The checked example answers block. The production service reaches a critical CVE through shop-app → payments-sdk → crypto-wrapper → openssl-3.0.12. A separate medium-severity logging CVE is covered by an active, explicit waiver, so it does not masquerade as the blocking reason.

Why this is a useful EyeProlog case

Real SBOM review is a graph problem plus policy: dependencies are transitive, vulnerability feeds change, exceptions expire, and reviewers need more than a red/green score. EyeProlog keeps the dependency path, policy, exception, and resulting action in the same inspectable reasoning model.

The example demonstrates:

• transitive dependency reasoning over RDF rdf/4 facts;
• severity policy and time-bounded waivers;
• a concrete deployment decision;
• an exact exposure path, not just “vulnerable”;
• a machine-readable upgrade conclusion that can round-trip to RDF.

Files

• ../sbom-vulnerability-response.pl — runnable combined example
• ../data/sbom-vulnerability-response-input.nq — RDF 1.2 input
• ../data/sbom-vulnerability-response-rules.pl — portable rules
• ../data/sbom-vulnerability-response-output.nq — materialized RDF result

Reproduce the boundary

rdf-to-prolog examples/data/sbom-vulnerability-response-input.nq \
  --rules examples/data/sbom-vulnerability-response-rules.pl \
  -o examples/sbom-vulnerability-response.pl

eyeprolog examples/sbom-vulnerability-response.pl

eyeprolog --goal write_results examples/sbom-vulnerability-response.pl \
  > examples/data/sbom-vulnerability-response-output.pl

prolog-to-rdf examples/data/sbom-vulnerability-response-output.pl \
  -o examples/data/sbom-vulnerability-response-output.nq

This site is open source. Improve this page.