Remediating security findings from scanners, pentests and researchers

What happens after a finding arrives?

In most organizations a finding lands in a scanner dashboard or a ticket, gets routed to the team that owns the code, and waits. When someone picks it up, they usually didn’t write the flagged code or the rule that flagged it. They read both, ask security what the finding means, decide whether it is real, write a fix, run the tests, and close the ticket, ideally after a rescan.

Findings tend to stall at the same four points:

• Ownership. Nobody is sure which team owns the code.
• Context. The assignee has to learn unfamiliar code and an unfamiliar vulnerability class.
• Doubt. Without a reproduction, it is unclear whether the finding is exploitable, so it loses to feature work.
• Verification. Nobody confirms the fix actually removed the vulnerability.

How remediation differs by finding source

SAST findings

Static analysis tools such as Semgrep, CodeQL, SonarQube, Checkmarx and Veracode report a rule, a CWE, a file and line, and often a source-to-sink trace. The remediation work is deciding whether the trace is real (the tool may not model a sanitizer or framework protection), fixing the root cause on every path that reaches the sink, and confirming the rule no longer fires on the patched code.

Dependency vulnerabilities and CVEs

Software composition analysis reports a package, an installed version and an advisory. The questions are whether the vulnerable function is reachable from your code, whether a fixed version exists, and whether upgrading breaks an API you rely on. Transitive dependencies may need an override or resolution entry. Verification means the lockfile resolves to a fixed version and the tests still pass.

Container findings

Container scanners report two different things. Operating-system package CVEs in the base image are fixed by rebuilding on a patched base. Dockerfile configuration findings, such as running as root, secrets baked into layers or unpinned images, are fixed in the Dockerfile itself, and the fix can break runtime behavior like file permissions. See a published run on a container running as root.

Infrastructure-as-code findings

Policy checks on Terraform, Kubernetes manifests or CloudFormation flag misconfigurations such as public storage, privileged pods or permissive network rules. The fix is a small change to a file, but its effect lands on running infrastructure, so review includes the plan or diff of what will change when it is applied.

Penetration-test findings

A pentest report describes a vulnerability as observed from outside, against a specific environment, with steps to reproduce. The remediation work is mapping that behavior back to the responsible code, reproducing it locally, fixing it, and confirming a retest passes.

Bug bounty and researcher reports

External reports vary in quality and come with expectations: an acknowledgment, a timeline, sometimes a disclosure date. Reproducing from the reporter’s steps is the first job, because it settles validity and severity. The fix then follows the same process as any other finding, with the reporter kept informed.

Internally discovered vulnerabilities

Findings from code review, threat modeling or incident follow-up often come with the best context and the least structure. Writing them up with a location, a vulnerability class and a reproduction makes them as actionable as a scanner finding.

Where BaseCobalt fits

BaseCobalt works downstream of all of these sources. It doesn’t replace the scanner, the pentest or the researcher; its input is the finding they produce. For each finding it investigates the code, reproduces the vulnerability, assesses exploitability, patches it, runs the project’s validation and rescans, and returns a verified fix ready for review. In early access, we are prioritizing finding types and sources based on what teams send us.