From Discovery to Resolution: A Single Source of Truth for Vulnerability Statuses

Continuous visibility from first discovery to final resolution across code repositories and container images, showing who fixed each vulnerability, when it was resolved and how long closure took. Kodem turns issue statuses into ownership for engineers, progress tracking for leadership and defensible risk reduction for application security.

Problem: The Accountability Gap 

AppSec leaders are not judged by how many vulnerabilities they can list. They are judged by how well they can prove that the issues that matter most are understood, owned and actually resolved everywhere they appear.

Accountability shows up in three questions:

  • Which vulnerabilities are truly exploitable in our environment?
  • Who is accountable for fixing them in each team?
  • Which of these issues are fully resolved everywhere, not just fixed in one branch or one service?

This is where most flows break down. Different teams declare something fixed at different moments. One group considers the issue resolved when a pull request merges. Another waits until the Jira ticket is closed. A third team points out that the affected image is still running in production. Leadership ends up with multiple conflicting answers to the same risk, with no clear understanding of when remediation actually occurred.

Security efforts tend to fail in the gap between discovery and resolution. The noise is not that you cannot find vulnerabilities. The noise is that you cannot state the real status in a way that everyone trusts.

Kodem addresses that gap by treating each risk as a single issue and assigning that issue a global status across the organization: Open, Dismissed or Resolved. The status is enforced across scopes so security, engineering and leadership work from the same truth. 

Solution: How Kodem Models an Issue

Kodem does not treat every alert as separate. It builds one issue around what actually matters.

An issue represents a real, correlated problem that can be exploited. Kodem identifies issues including package vulnerabilities, malicious packages, code weaknesses and exposed secrets. For example, a code weakness like an unsafe deserialization function that is actually executed in a running workload becomes an exploitable issue. The same issue can appear in more than one place at once, for example in a code repository and in the container image built from that code.

Instead of flooding every team with duplicates, Kodem links those observations back to a single issue within the project context. That single issue represents the unit of ownership at the project and resource level, not scattered across your entire organization. That contextual issue is what gets a status, making it actionable for the team responsible for that specific codebase or application.

One Global Status Across the Organization

Each issue carries one global status that is enforced consistently across teams, products and scopes. That status is the source of truth.

  • Open means the issue is still detected in one or more resources and still requires management, which can include investigation, prioritization or remediation. 
  • Dismissed means the issue has been reviewed and intentionally accepted as not requiring action, with the rationale accepted for traceability. 
  • Resolved means the issue is no longer detected in any associated resource across the organization after remediation has been applied and verified by scanning. Verification confirms that the vulnerable package was upgraded and / or the code has been fixed and those resources are scanned with no issue detected. 

Differentiator: Resolved Means Resolved Everywhere 

Most solutions treat resolved as gone from view. The record disappears. This creates more work later and makes leadership uneasy.

Resolved in this model is different:

  • Resolved means the issue is gone everywhere it was detected, not just fixed in one branch or one service.
  • Resolution is backed by evidence. This includes what was changed, where it was last detected and proof that the risky behavior or vulnerable package is no longer present.
  • Time to resolution is captured. You know when the issue was first discovered, when it was remediated and how long that took.
  • Ownership is visible. You know who drove the change that actually removed the exposure.

This turns Resolved from a cosmetic label into a defensible state. You are not saying we think this is handled. You are saying it is out of the environment and here is proof.

Differentiator: Resolution That is Aware of Repos, Teams and Business Units

Engineering organizations manage many resources: code repositories, base images and deployed applications - each often owned by a different team. Kodem uses scopes to define and filter these resource groups, giving each team targeted visibility and access to just the resources they own. A scope might be a product area, a business unit, a regulated environment or a specific team.

In practice, an issue may be fixed in one scope while still running in another. If status ignores that reality, leadership gets a false sense of closure. 

Kodem’s global issue model reflects this reality across scopes:

  • If an issue has been resolved in one scope, that status appears on the issue summary for that scope.
  • If that same issue is still open in a different scope, the global status remains open until resolved everywhere it is detected.
  • You can see both truths at once. One team is done, another team still owns open issues.

This approach ensures credit where it is due and shared visibility across the organization: engineers are recognized for what is remediated and security personnel see exactly what remains exposed. With scope-aware resolution, Kodem turns that visibility into operational clarity that teams can trust.

Operational Impact

When issue status is consistent, scope aware and backed by evidence, three critical AppSec benefits emerge immediately:

  • Engineering gets finality. Once work lands and the exploitable risk is gone, they get credit for closure. They are not asked to explain the same fix over and over.
  • AppSec gets an audit trail. Resolution is no longer a story told in Slack. It is captured in the lifecycle of the issue as part of the system of record.
  • AppSec programs achieve compliance readiness and measurable risk reduction. Formal audit trails support SOC 2, PCI DSS, and other compliance frameworks while enabling concrete metrics like mean time to remediation and attack surface reduction.

Why Kodem’s Issue Statuses Matter

Security teams are no longer judged by how many findings they can surface. They are judged by how well they can identify exploitable risk, drive it to remediation across all the places it runs and prove that it is gone.

Evidence of risk reduction builds trust, not evidence of volume.

A unified issue model, a single global status and a resolved state that reflects verified remediation across scopes gives you that evidence. Tying priority to real exposure and turns closure into something the organization can defend.

Table of contents

Related blogs

Prompt Injection was Never the Real Problem

A review of “The Promptware Kill Chain”Over the last two years, “prompt injection” has become the SQL injection of the LLM era: widely referenced, poorly defined, and often blamed for failures that have little to do with prompts themselves.A recent arXiv paper, “The Promptware Kill Chain: How Prompt Injections Gradually Evolved Into a Multi-Step Malware,” tries to correct that by reframing prompt injection as just the initial access phase of a broader, multi-stage attack chain.As a security researcher working on real production AppSec and AI systems, I think this paper is directionally right and operationally incomplete.This post is a technical critique: what the paper gets right, where the analogy breaks down, and how defenders should actually think about agentic system compromise.

January 16, 2026

Part 2 — Automotive Software Security: Beyond Compliance, Toward Proof

Follow-on to Part 1: Translating regulation into runtime evidence.

November 12, 2025

Part 1 — Automotive Software Security Readiness: A Researcher’s Field Guide

Are You Ready for UN R155? The Real Work Behind Automotive Software Security Compliance

November 12, 2025

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo

A Primer on Runtime Intelligence

See how Kodem's cutting-edge sensor technology revolutionizes application monitoring at the kernel level.

5.1k
Applications covered
1.1m
False positives eliminated
4.8k
Triage hours reduced

Platform Overview Video

Watch our short platform overview video to see how Kodem discovers real security risks in your code at runtime.

5.1k
Applications covered
1.1m
False positives eliminated
4.8k
Triage hours reduced

The State of the Application Security Workflow

This report aims to equip readers with actionable insights that can help future-proof their security programs. Kodem, the publisher of this report, purpose built a platform that bridges these gaps by unifying shift-left strategies with runtime monitoring and protection.

Get real-time insights across the full stack…code, containers, OS, and memory

Watch how Kodem’s runtime security platform detects and blocks attacks before they cause damage. No guesswork. Just precise, automated protection.

Stay up-to-date on Audit Nexus

A curated resource for the many updates to cybersecurity and AI risk regulations, frameworks, and standards.

Gal Sapir
Publish date

0 min read

Compliance