Vulnerability Management

Indian Hill Labs uses vulnerability data as an engineering and risk-management input across the software artifact lifecycle. The goal is not to optimize a headline vulnerability count; it is to identify relevant risk, prevent avoidable exposure, document applicability, and remediate supported artifacts promptly.

Policy control	Value
Status	Published engineering policy
Effective date	2026-08-30
Scope	Generally available and supported Indian Hill Labs software artifacts
Priority source	CISA Known Exploited Vulnerabilities Catalog
Review trigger	Material process change, intelligence-source change, or policy revision

Pre-release assessment

Before release, an artifact must undergo vulnerability assessment against maintained intelligence. The assessment must:

1. identify the exact immutable artifact digest;
2. inventory discoverable components and versions;
3. record scanner, database, and assessment-time context;
4. identify CISA Known Exploited Vulnerabilities (KEV);
5. triage Critical and High findings against release gates;
6. evaluate applicability when a reported match does not accurately describe artifact risk; and
7. preserve results or summaries as release evidence.

A scan result is time-bound. A clean result means that no findings were identified under the assessment's data, tool, configuration, and detection limits; it does not guarantee that the artifact contains no unknown vulnerability.

Reported versus applicable

A reported vulnerability is a vulnerability record associated by a detection method with a component or artifact. An applicable vulnerability is a reported vulnerability whose affected conditions are present and relevant to the artifact as built or operated within its declared scope.

Applicability analysis may consider:

• whether the affected component and version are actually present;
• whether vulnerable code is included, reachable, or invoked;
• whether the affected feature is enabled;
• whether the vendor's version or backport information differs from upstream numbering;
• whether configuration or build-time choices remove the affected condition; and
• whether a fix is already present in the supplied package.

Applicability analysis requires evidence. Uncertainty remains under investigation; it is not automatically treated as not affected.

Release gates

The engineering objective is to release with zero known applicable vulnerabilities. At minimum:

• CISA KEV findings require explicit disposition and normally block release while applicable.
• Applicable Critical and High findings block release unless an authorized, documented exception is approved.
• Medium and Low findings are assessed and scheduled according to risk and maintenance planning.
• Exceptions must be scoped, time-bounded where feasible, and transparent about consumer impact without exposing sensitive internal detail.

Objective, not an absolute guarantee

Zero known applicable CVEs is an engineering objective evaluated with available vulnerability intelligence and evidence at a point in time. It is not a claim that unknown vulnerabilities do not exist or that all deployment risk has been eliminated.

Remediation objectives

The following targets are internal engineering objectives, measured from confirmation that a vulnerability is applicable to a supported artifact or from an equivalent actionable trigger defined by the response process.

Classification	Engineering objective
CISA KEV	24 hours
Critical	72 hours
High	7 calendar days
Medium	14 calendar days
Low	30 days or next planned release

Not contractual SLAs

These targets guide engineering prioritization. They are not contractual service-level agreements, warranties, or guaranteed resolution times. A separate written agreement must explicitly establish any contractual commitment.

Severity is not the only prioritization factor. Active exploitation, exposure, reachability, exploit prerequisites, safety impact, affected population, fix availability, and compensating controls may accelerate or modify response.

CISA KEV handling

When a reported vulnerability appears in the CISA KEV Catalog, the assessment receives expedited review. The team determines whether the affected condition is present, documents the status, and prioritizes containment or remediation. If the vulnerability is applicable to a supported released artifact, the 24-hour engineering objective governs the initial remediation response, which may include a fixed artifact, withdrawal, mitigation, or other risk-reducing action appropriate to the product.

VEX

VEX communicates artifact-specific vulnerability status such as affected, not affected, fixed, or under investigation. A VEX statement should include the product identity, vulnerability identifier, status, rationale, and relevant time or version context.

VEX complements scanner output; it does not erase it. Statements are reassessed when the artifact, vulnerability intelligence, or supporting evidence changes.

Continuous monitoring

Supported release digests are monitored as vulnerability databases, advisories, exploit intelligence, and supplier information evolve. New or changed findings enter the same applicability and prioritization process used before release.

Current private engineering implementation

The details below describe candidate automation and private registries. They document operating evidence but do not make those candidates generally available.

For this project, GitLab advisory-driven continuous vulnerability scanning and Container Scanning for Registry are enabled. The latter reacts to pushes of the registry latest tag; the assurance tiers intentionally use explicit digest and tier tags instead. Weekly Secure, Hardened, and Validated rebuild-and-scan schedules therefore regenerate both GitLab and Grype reports, refresh CISA KEV comparison and SBOM evidence, and update the assurance dashboard. Scheduled pipelines do not expose publication or deployment gates.

The GitLab registry cleanup policy runs weekly, selects candidate-* tags older than 30 days, retains the ten most recent matching tags per image, and excludes 10.* release labels plus sha256-* signature/attestation tags. Cleanup affects tags; signed release records and consumers remain digest-bound.

Azure Container Registry uses the scheduled ihl-weekly-candidate-cleanup task at 07:00 UTC each Sunday. Its system-assigned identity has Container Registry Repository Contributor through an ABAC condition limited to aspnet-runtime and reference-api. The task selects only candidate-* tags older than 30 days and retains the ten most recent matches per repository. It deliberately omits untagged-manifest deletion so digest consumers and OCI signature referrers are not garbage-collected. The controlled configuration and successful dry-run result are recorded in compliance/azure/acr-governance.json. Azure currently classifies acr purge as a preview feature, so this control requires periodic review.

Monitoring records should preserve:

• artifact digest and support status;
• detection or notification time;
• current applicability status and rationale;
• severity and known exploitation information;
• remediation owner and target;
• available mitigation; and
• fixed or superseding artifact identity when resolved.

Remediation outcomes

A finding may result in a rebuilt artifact, dependency update, configuration change, mitigation guidance, withdrawal, documented non-applicability, accepted exception, or support-status change. A fixed release receives a new digest and must be evaluated as a new artifact. Consumers should verify and promote that new digest rather than assuming a mutable tag identifies the intended fix.