product smithguardaccess public-read-onlyevidence linked
Every claim carries its evidence.
SmithGuard checks one exact public package or artifact coordinate against evidence-linked malware and vulnerability records. It returns the current result, incident classification, source reports, corrections, coverage, and explicit unknowns.
What SmithGuard makes available
A narrow public service built to answer one question carefully: what does the current evidence say about this exact public artifact?
Exact public-artifact assessment
Submit one exact public package or artifact coordinate. SmithGuard returns only evidence connected to that artifact.
Evidence and correction state
Results keep incident classification, source reports, timing, confidence, revisions, and correction state together so a finding can be checked rather than merely repeated.
Honest unknowns
Coverage extends beyond npm and PyPI and is reported separately by ecosystem and source lane. The live coverage document shows which accepted coordinate types have supported evidence and which remain unknown.
Read-only verification
The public service is accountless and read-only. Public verification keys preserve the ability to check signed records over time.
example illustrativeshape public-contractaction investigate
The answer keeps its limits attached
See the evidence shape, not just a verdict
A SmithGuard assessment keeps the result beside its incident classification, coverage, explicit unknowns, and any separate time-bounded early warning. This excerpt is illustrative, not a live assessment.
When matching malware evidence is available, SmithGuard keeps it in the response and labels the incident as malicious or compromised. Vulnerability evidence is labeled vulnerable.
- Result
affectedmeans a match;possibly_affectedmeans the exact match is not confirmed;not_affectedapplies only within the stated coverage;conflictingmeans reliable evidence disagrees; andunknownmeans the evidence cannot support an answer. - Incident classification
malicious,compromised, orvulnerableexplains what kind of incident the evidence describes. - Coverage and unknownsThe evidence boundary behind the answer and what it cannot support.
- Early warningA separate Emerging / Unverified lead with an expiry, not an incident classification.
{
"result": "affected",
"incidents": [
{
"status": "confirmed",
"confidence": "confirmed",
"classification": "compromised"
}
],
"coverage": {
"ecosystem": "npm",
"stage": "matched",
"result": "supported",
"as_of": "2026-09-01T00:00:00Z"
},
"unknowns": [],
"preliminary_warnings": []
}record_state emerging-unverifieduse investigate-before-acting
Early warnings stay visibly early
Emerging / Unverified
Potential issue detected from limited or early evidence. Investigate before acting.
An early lead can come from social discovery or another permitted public source. Official incident repositories continue through the normal evidence path. The label describes the evidence level, not the scanner that found it.
Use the public boundary as designed
Use one exact public package or artifact coordinate at a time.
Do not submit source code, private repositories, lockfiles, SBOMs, or private inventories to the public service.
Treat Emerging / Unverified warnings as investigation leads, not confirmed incidents.
A recommendation or record is information, not authorization to change a system.
Use the live coverage document and OpenAPI contract for exact operational facts.