Security Scanning Roadmap: Closing the Gaps

[brandonrc]

Overview

Artifact Keeper already has a solid security scanning foundation: 7 integrated scanners (dependency, container image, filesystem, Grype, Incus/LXC, OpenSCAP compliance, and quality checks), SBOM generation in CycloneDX and SPDX formats, a policy engine with 7 enforcement rule types, and cryptographic signing for APT/YUM/APK/Conda repos.

This discussion outlines where we want to take security scanning next, organized into three phases. Looking for feedback on priorities and anything we are missing.

---

Phase 1: Fill the Gaps

These are capabilities that enterprise users expect from an artifact registry today.

Secret Detection Scanner

Detect exposed secrets (API keys, tokens, passwords, private keys) inside artifacts before they reach production. Leaked credentials in published packages are one of the most common supply chain risks, with tens of thousands found in public registries each year. We would integrate an engine like trufflehog or gitleaks, implementing our existing Scanner trait so it slots into the current scanning pipeline.

License Compliance Scanner

The database schema and policy tables for license scanning already exist but the scanner itself is not wired up. This would parse license fields from package manifests (package.json, Cargo.toml, pom.xml, gemspec, nuspec, etc.), match against the SPDX license list, and evaluate against configurable allow/warn/block policies. Table-stakes for any organization with legal compliance requirements.

Malware Detection

The malware scan type is defined in our schema but has no implementation. The plan is to integrate with known-malicious package databases (like the OpenSSF Malicious Packages repository) to check uploaded artifacts against a continuously updated index of compromised packages. Stretch goal: behavioral analysis of install scripts in npm/PyPI packages for suspicious patterns.

---

Phase 2: Proactive Security

Move from point-in-time scanning to continuous, context-aware security.

Continuous CVE Monitoring

Currently, artifacts are scanned on upload or manual trigger. If a new CVE is disclosed next week for a library you uploaded last month, you would not know until someone re-scans. We want a background job that periodically checks advisory databases and automatically re-evaluates existing artifacts, updating scores and optionally triggering notifications.

EPSS and KEV Enrichment

Not all critical CVEs are equal. The Exploit Prediction Scoring System (EPSS) provides a probability of exploitation in the next 30 days, and CISA's Known Exploited Vulnerabilities (KEV) catalog flags what is actively being used in the wild. Industry research suggests only about 12% of "critical" CVEs truly warrant that rating. Enriching our findings with these data sources would dramatically reduce alert fatigue.

Cross-Artifact Impact Graph

When a new vulnerability drops, you need to answer: "which of my Docker images, Helm charts, and deployed artifacts contain this library?" Using SBOM component data, we can build a reverse dependency index that traces the blast radius of any CVE across your entire registry.

---

Phase 3: Differentiation

Capabilities that go beyond what most registries offer.

Contextual/Reachability Analysis

Analyze whether your application code actually calls a vulnerable function, rather than flagging every CVE equally. This can eliminate up to 75% of false positives. Start with heuristics (direct dependency = higher risk, transitive = lower) and add call-graph analysis for Java, JavaScript, and Python over time.

IaC Misconfiguration Scanning

Extend the quality check framework to scan Dockerfiles, Helm charts, and Terraform files for security misconfigurations: containers running as root, overly permissive IAM, missing encryption, exposed ports. Integrate with tools like Checkov or hadolint.

Operational Risk Scoring

Go beyond vulnerabilities to assess whether dependencies are still safe to rely on: end-of-life detection, maintainer activity, dependency freshness (versions behind latest), and typosquat detection. Surface as a risk score alongside the existing security grade.

Binary-Level Deep Scanning

Scan compiled binaries to detect vendored or bundled dependencies invisible to manifest-only analysis. Go binaries embed module info, Java fat JARs contain nested libraries, Rust binaries include crate version strings. Extracting this gives complete visibility into what is actually shipped.

---

Current State for Reference

Capability	Status
Dependency scanning (OSV.dev + GitHub Advisory)	Shipped
Container image scanning (Trivy)	Shipped
Filesystem scanning (Trivy, 20+ formats)	Shipped
Grype fallback scanner	Shipped
Incus/LXC scanning	Shipped
OpenSCAP compliance	Shipped
SBOM generation (CycloneDX + SPDX)	Shipped
Security scoring (A-F grades)	Shipped
Scan policies (7 rule types)	Shipped
Code signing (RSA, APT/YUM/APK/Conda)	Shipped
Dependency-Track integration	Shipped
Quality checks (metadata + Helm)	Shipped
Secret detection	Planned (Phase 1)
License compliance	Planned (Phase 1)
Malware detection	Planned (Phase 1)
Continuous CVE monitoring	Planned (Phase 2)
EPSS/KEV enrichment	Planned (Phase 2)
Impact graph	Planned (Phase 2)
Reachability analysis	Planned (Phase 3)
IaC scanning	Planned (Phase 3)
Operational risk scoring	Planned (Phase 3)
Binary deep scanning	Planned (Phase 3)

Feedback welcome. What would you prioritize? Anything missing?

[dragonpaw]

For me personally, the most important of these would be the continuous CVE monitoring.