Who should be accountable for securing open source projects that are scanned with AI tools?

Accountability Starts with the People Who Can Actually Change the Code

AI scanning can surface patterns faster than manual review, but accountability for open source security still belongs with the people who govern the project and the security function that can act on the result. That division matters because scans create findings, while maintainers, reviewers, and sponsoring security teams make remediation decisions, set priorities, and accept or reject residual risk. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control-language anchor for assigning responsibilities, tracking actions, and preserving accountability across review and remediation workflows. In practice, many teams discover gaps in ownership only after a finding has already been confirmed and nobody is empowered to merge the fix.

What AI Scanning Changes, and What It Does Not

AI tools can improve coverage by flagging dependency issues, insecure patterns, and code fragments that deserve closer inspection. They are useful as an accelerant, not as a decision-maker. The practical boundary is simple: the tool can identify candidates, but a human owner must decide whether the issue is real, whether it affects the project’s release path, and whether the fix is safe to ship.

That means accountability should be explicit at three levels. First, project maintainers own the codebase and therefore own the technical response. Second, a sponsoring security team should own the review process when the project is part of a broader organisation or programme, because someone must set severity rules, evidence standards, and escalation thresholds. Third, release or governance leadership should own risk acceptance when a finding is deferred, because “we saw it” is not the same as “we accepted it.”

A useful way to think about the workflow is:

• the AI tool produces a candidate finding;
• a maintainer or reviewer validates whether it is actionable;
• the security function tracks it to closure or documented exception;
• the project owner decides on remediation timing;
• the organisation records who approved the final state.

This distinction matters most when AI output is noisy, because false positives can otherwise blur responsibility and slow down maintenance. It also matters when a project has multiple contributors, since “community-owned” does not mean “nobody owns it.” The governance model has to identify a named decision-maker for fixes, exceptions, and disclosure, especially where a vulnerable open source package may be consumed downstream by many teams. Guidance of this kind aligns with the control expectation that accountability, monitoring, and remediation should be defined rather than implied.

When Shared Stewardship Becomes a Governance Problem

Tighter review processes often increase coordination overhead, requiring organisations to balance faster scanning against slower decision-making. That tradeoff becomes visible in open source projects with distributed maintainers, volunteer contributors, or weak release discipline. In those cases, the right answer is not to shift accountability to the AI vendor or the scanning platform, because neither one owns the software lifecycle.

There are a few common edge cases. A foundation may provide infrastructure while individual maintainers control merges. A company may sponsor scanning for a project it does not own. A downstream consumer may find a defect in a dependency but still need the upstream maintainer to approve the patch. In each case, the accountable party is the one with authority to change the code or formally accept the risk, while others may contribute evidence, funding, or triage support.

Where teams disagree is on how far the sponsor’s responsibility extends. The consensus view is that sponsorship creates accountability for the review process and the response workflow, but not necessarily ownership of the upstream code. The maintainer remains accountable for the repository itself, while the sponsor must ensure that findings are not ignored, lost, or left without escalation. That separation is especially important when disclosure timing, dependency impact, or release pressure creates tension between speed and safety.

For that reason, open source teams should document who approves remediation, who can defer a fix, and who communicates externally if the vulnerability is confirmed. Without those decisions, AI-assisted scanning can increase visibility while leaving the hardest governance question unresolved.

Practitioner Guidance

What to prioritise: assign one named owner for triage, one for remediation approval, and one for exception decisions before you run scans at scale. If those roles are merged, teams can move quickly; if they are vague, findings linger and accountability disappears.

What to verify: confirm that the project has a path for accepting or rejecting findings, recording rationale, and tracking closure through release. The key test is whether a maintainer or sponsor can point to the decision record without informal follow-up.

Practitioner takeaway: AI scanning improves detection, but accountability only exists when a human role has authority to act on the finding, own the risk, and close the loop.

Related resources from NHI Mgmt Group

• Who is accountable when an open-source AI assistant exposes credentials or allows account takeover?
• Who should be accountable for securing low-code AI projects and copilots?
• Why do traditional SCA tools struggle in environments that use AI-generated code and heavy open source reuse?
• What makes agentic AI an NHI governance issue?