A coding agent can propose a dependency upgrade in seconds. The harder question arrives one step later: what stops that proposed fix from becoming the next problem?

Two announcements on October 27 put controls on different sides of that moment. IBM's Bob Premium Package for DevSecOps describes a guard that intercepts some risky changes before they reach disk. Black Duck's Signal Agentic Fix describes a loop that scans, proposes repairs, checks them and sends them for human approval. Neither announcement is proof that a generated patch is safe to merge.

IBM puts a stop before the write

IBM says SafeWrite intercepts AI-proposed file edits and package-install commands in memory. For newly introduced vulnerable dependency versions, it substitutes the nearest fixed version when one is known. If no known fix is available, it blocks the installation. It also rejects direct edits to lockfiles.

That is a specific promise, not a claim to catch every unsafe change. A dependency guard can act on a known vulnerable version. An authorization mistake in application logic is a different problem. IBM separately describes read-only, AI-driven scans that reason about repository context, run against a Git snapshot and do not read secret files.

The useful distinction is between prevention and investigation. Stopping a known-bad package version before a write is different from explaining a possible flaw after reading a codebase. Teams evaluating the package should ask which control handled a finding, what it changed and what evidence remains.

Black Duck puts a check after the fix

Black Duck says Signal Agentic Fix combines static application security testing (SAST) and software composition analysis (SCA) with AI triage and fix generation. Its announced sequence is scan, triage, fix, validate and submit. Validation includes re-scanning the repaired code; customer-defined compliance checks and functional tests are optional additions.

That last distinction matters. A clean re-scan answers a narrower question than a test suite checking whether the application still behaves as intended. The company's announcement describes both capabilities, but does not say every deployment runs every possible check.

In the coding-agent version, Black Duck says the coding agent implements the proposed fix under the team's existing controls, with the developer approving or rejecting each change before it is applied. In the pipeline version, generated and validated changes become pull requests for review before merging. These are different handoff points. Buyers should not flatten them into one promise of autonomous repair.

The calendar is part of the specification

Black Duck lists Signal Agentic Fix for Claude Code as available in Early Access on October 27. It says further coding-agent and pipeline integrations are coming in the following weeks. That is not a statement that every described integration is generally available today.

IBM's announcement puts intelligent pull-request review in November, starting with GitHub and GitHub Enterprise. It describes the review as advisory, with developers and reviewers retaining final merge authority. GitLab support is planned for a later release. An announced roadmap should not be mistaken for an installed control.

A green check needs a boundary

There is an existing place to enforce the distinction between advice and permission. GitHub's protected-branch documentation describes required approving reviews and required status checks. It also notes that administrators and roles with bypass permission are exempt by default unless the restrictions are applied to them. A review gate is only as strong as the routes around it.

Nor is one scanner the whole verification job. NIST's developer-verification guidance recommends a mix of techniques, including threat modeling, static scanning, automated testing, black-box tests and fuzzing. It calls them minimum techniques, not the totality of verification.

For an evaluation, ask for the original finding, the exact diff, the checks that actually ran and the person or policy allowed to approve the change. Keep failed tests and unsupported cases in the record. A tool that generates more fixes without making those answers clearer may simply move the review queue.

The promising part of these announcements is where they draw the line: before a risky write, after a proposed repair and before a merge. The line worth defending is simpler. A patch is an argument that the code should change. It is not permission to change it.

Reporting note: This article analyzes public vendor announcements and published guidance. GigSoul has not tested either package. Product behavior and availability above are attributed to the vendors, not independently measured results.