Pilot IBM Bob’s November DevSecOps Review Without Giving It Merge Authority

What changed in IBM Bob’s DevSecOps package

IBM announced the Bob Premium Package for DevSecOps on October 27. The company says SafeWrite intercepts AI edits and package installs in memory, can substitute the nearest known fixed dependency version, blocks an install when no known fix exists and rejects direct lockfile edits. IBM also describes real-time SAST, supply-chain, secret and misconfiguration checks.

The announcement says intelligent pull-request reviews become available in November through Bob Shell as GitHub Actions. A developer triggers a review with “/review”; IBM describes the findings as advisory and says developers retain merge authority. GitHub and GitHub Enterprise are the named starting platforms, with GitLab planned for a later release.

Pricing is not published on the announcement page. The page links to a trial, but teams should confirm that the DevSecOps package, November review capability, geography and support terms are actually enabled for their account before designing a rollout. Deep Security did not test IBM Bob; capabilities here are vendor claims.

• Who can use it: teams able to obtain the Bob Premium Package and its DevSecOps entitlement.
• Initial platform: GitHub and GitHub Enterprise, according to IBM; GitLab is planned.
• Workload: dependency edits, generated code, repository sweeps and advisory pull-request review.

Why this feature deserves a bounded pilot

AI-assisted development can propose vulnerable dependencies, insecure code or secrets faster than conventional review catches them. An Infosecurity Magazine article on November 2 reflects current independent attention to AI software-supply-chain risks, but it does not validate IBM's product claims or establish adoption.

The useful change is not “AI reviews AI.” It is the opportunity to place a security check at the moment an AI edit is proposed and another advisory review at the pull request. Those controls still depend on repository context, scanner coverage, correct findings and developer review.

Choose a non-production repository with representative languages, package managers and branch protection. Do not begin with a critical release path, regulated codebase or repository containing secrets.

Define the pilot contract before enabling it

Write down the package entitlement, supported repositories, GitHub Action permissions, data-retention terms, model-processing location, secret-file behavior and who can trigger “/review.” IBM says its read-only scans use a Git snapshot and do not read secret files; confirm that claim against the current contract and tenant documentation.

Retain existing SAST, dependency scanning, secret detection, code-owner review and branch protection. Do not grant Bob write, approval or merge permissions merely to simplify the pilot. Pin the action version or commit if the integration supports it, and review workflow changes like production code.

Create an exception path for false positives and a rollback that removes the action and associated token. Name one engineering owner and one security owner for every repository.

• Access: least-privilege GitHub token or app permissions.
• Control: required human reviewers and protected branches stay enabled.
• Evidence: keep review output, developer disposition and final diff for the pilot window.

Run a seeded, reproducible pull-request test

Create a disposable branch with organization-approved synthetic cases: a known vulnerable dependency version with a documented fix, a package with no known fix, an intentionally insecure code pattern covered by your existing scanner, a harmless look-alike and a direct lockfile edit. Never seed a real secret.

Trigger the normal workflow and “/review.” For each finding, record the file and line citation, rule or vulnerability reference, suggested change, whether the suggestion preserves behavior, and whether the existing controls also detected it. Restore the branch after the test.

Do not treat a blocked install or a clean review as proof that the repository is secure. SafeWrite and PR review cover only the behaviors, ecosystems and rules they can see.

Use an acceptance scorecard—not enthusiasm

Set pilot thresholds before testing: findings must cite the correct location; suggestions must not silently expand scope; known seeded cases must be surfaced by at least one required control; false positives must remain reviewable; and no workflow path may bypass human approval.

Track duplicate findings across Bob and existing scanners, reviewer time, dismissed findings with reasons, unsupported languages or package managers, action failures and permission changes. Compare results by repository type rather than collapsing them into one vanity number.

The scorecard shown here is qualitative and contains no measured IBM results. A failed threshold should pause expansion until the cause is understood.

Limitations, availability and next steps

IBM's announcement is the primary source for functionality and timing. The exact November release date, plan pricing, repository limits, supported languages and package managers are not specified on that page. Availability may depend on tenant enablement or contract terms; verify in the product and with IBM.

AI review can miss vulnerabilities, hallucinate a rationale, propose a risky update or create alert fatigue. Read-only scanning does not prove complete visibility, and a nearest fixed dependency version can still break compatibility. Existing tests, security scanners and human review remain required.

If the pilot passes, expand one repository class at a time. Re-check permissions and branch protection, document known gaps, publish the exception path and schedule a review after product updates. Do not grant merge authority as a reward for better signal.