AI Code Review Security: Torvalds Backs AI in Kernel

Last Updated: August 25, 2026

AI code review can help developers find real defects, but it should not be treated as an autonomous security authority.

That is one of the clearest lessons from the Linux kernel's recent experience with Sashiko, an automated code-review system that uses large language models to inspect proposed kernel changes.

Linus Torvalds has made clear that Linux is not an anti-AI project. His position, however, should not be interpreted as approval for blindly accepting machine-generated findings or code. Linux's own development documentation still requires human responsibility, verification, testing, attribution, and compliance with the normal kernel development process.

For enterprise security teams, this distinction matters.

The practical question is no longer simply:

Should developers use AI?

A better question is:

What controls must remain in place when AI becomes part of code review?

This article examines that question through the Linux and Sashiko case, then turns the lessons into a practical framework for security leaders, AppSec teams, engineering managers, and developers.

Key Findings

• Linus Torvalds has publicly defended useful AI tools in Linux development, but human responsibility remains part of the development process.
• Sashiko's maintainers report that their system found 53.6% of historical bugs in a specific retrospective test using Gemini 3.1 Pro. This is a Sashiko-reported result, not an independently audited universal AI accuracy rate.
• Sashiko's project documentation estimates false positives within roughly a 20% range, based on limited manual review, and describes its output as probabilistic.
• Linux kernel documentation warns that poor-quality AI-assisted security reports can create additional work for maintainers when findings are speculative, inaccurate, or poorly verified.
• Linux requires a human contributor to review AI-generated code, take responsibility for it, comply with licensing requirements, and provide their own certification.
• Enterprise AI code review should complement, rather than silently replace, secure code review, SAST, dependency analysis, testing, threat modeling, and human validation.

What Did Linus Torvalds Actually Support?

Torvalds defended the use of AI as a development tool, not the idea that AI output should bypass normal engineering controls.

During the July 2026 Linux discussion around AI-assisted development and Sashiko, Torvalds rejected a blanket anti-AI position and described AI as a useful tool.

The broader context is covered by The Register's reporting on the Linux AI debate.

That distinction matters because headlines can make the story sound broader than it is.

Torvalds did not establish a rule saying:

• AI findings should automatically be accepted
• AI-generated patches should skip human review
• maintainers must trust AI assessments
• automated review should replace existing testing
• security decisions should be delegated to a model

The Linux project's own documentation points in a more controlled direction.

Its official AI Coding Assistants guidance states that contributors using AI must still follow the normal kernel development process.

An AI agent cannot add a Signed-off-by tag on behalf of a developer. The human submitter remains responsible for reviewing the generated code, ensuring licensing compliance, certifying the contribution, and accepting responsibility for what is submitted.

For enterprise security programs, that is a more useful lesson than debating whether someone is “pro-AI” or “anti-AI.”

What is Sashiko?

Sashiko is an agentic code-review system designed specifically for Linux kernel patches.

Its public GitHub repository describes a multi-stage review process that can examine areas such as:

• architecture
• implementation correctness
• execution flow
• memory and resource management
• synchronization
• security
• hardware behavior
• verification
• final report generation

This is more structured than simply sending a patch to a model with a single prompt asking whether the code contains a bug.

Sashiko attempts to provide the model with repository context and review the same change from several technical perspectives.

The project's public Sashiko Bugs Repository states that Sashiko is an open-source Linux Foundation project and that Google supports the public reviewing service with compute resources and model tokens.

What Sashiko's 53.6% Result Actually Means

This number needs careful interpretation.

Sashiko's maintainers report that, using Gemini 3.1 Pro, their evaluation detected 53.6% of bugs in an unfiltered selection of the last 1,000 upstream commits carrying fix-related tags.

According to Sashiko's published methodology, these were historical bugs that had already gone through the normal development process before later being fixed.

That is an interesting result.

It is not, however, evidence that every AI code reviewer catches 53.6% of software defects.

It does not establish:

• a universal AI code-review detection rate
• performance across all enterprise applications
• performance across every programming language
• performance across every AI model
• equal performance across vulnerability classes
• independent validation of Sashiko's benchmark
• superiority over qualified security reviewers
• a safe replacement for existing AppSec controls

What the Benchmark Shows and What It Does Not

The published test suggests	The published test does not establish
Sashiko can identify real bugs in historical kernel changes	Every AI reviewer achieves the same accuracy
Structured AI review can produce useful findings	AI can replace Linux maintainers
AI may catch defects missed during previous review	Humans are less effective overall
Kernel-specific context can improve usefulness	The result transfers to every codebase
Automated review deserves evaluation	Findings can be accepted without validation

The right enterprise response is therefore not:

“AI catches 53.6% of bugs.”

What About False Positives?

Sashiko's own documentation says its false-positive rate is harder to measure and estimates it to fall within roughly a 20% range, based on limited manual review.

The project also acknowledges that some findings fall into a gray area.

That qualification is essential.

Security teams already deal with alert fatigue from:

• vulnerability scanners
• monitoring systems
• static analysis
• dependency alerts
• threat feeds
• endpoint tools

Adding another source of unverified findings can increase rather than reduce operational work.

A useful AI code-review system should therefore be measured on more than the number of findings it produces.

Teams should track questions such as:

• How many reported findings are confirmed?
• How many are dismissed?
• How many known defects are missed?
• How long does validation take?
• Does the tool identify the vulnerable execution path correctly?
• Can a reviewer reproduce the problem?
• Are proposed fixes correct?
• Does repeated analysis produce reasonably consistent results?

Finding more “issues” is not automatically better.

A system that produces hundreds of weak findings can consume more engineering time than it saves.

Linux is Already Seeing the Cost of Poor AI Security Reports

Linux's official security documentation now addresses this problem directly.

The kernel's Security Bugs guidance discusses the growing number of reports produced with AI assistance and the burden poor-quality reports can place on maintainers.

The documentation emphasizes verification, threat-model understanding, reproducibility, and tested fixes.

Several lessons are directly relevant to enterprise AppSec teams.

Excessively Long Reports

Generated reports can bury the important technical details under unnecessary explanation.

A maintainer or security engineer normally needs information such as:

• affected versions
• affected files or functions
• triggering conditions
• reproducible behavior
• realistic impact
• technical evidence

A long report is not automatically a thorough report.

Speculative Security Impact

An AI reviewer may identify suspicious code and then generate a dramatic attack scenario that has not actually been demonstrated.

Linux's security guidance emphasizes understanding the relevant threat model.

This principle applies equally to enterprise applications.

A possible null dereference is not automatically remote code execution.

A questionable authorization branch is not automatically account takeover.

A suspicious memory operation is not automatically exploitable.

The security impact must be validated.

Missing Reproducers

Where possible, serious findings should be reproducible.

A reproducible test helps distinguish a genuine vulnerability from a plausible-sounding model interpretation.

Untested Fixes

Finding a possible defect is only part of the work.

A proposed fix must also be:

• reviewed
• built
• tested
• checked against expected behavior
• evaluated for unintended side effects

The broader lesson is simple:

AI-generated security findings should enter a verification workflow, not a trust workflow.

AI-Generated Code, AI Code Review, and AI Bug Reports Are Different Risks

Security teams should separate three related but different activities.

Use of AI	Main security question	Common failure
AI generates code	Is the code correct, secure, licensed, and understood?	Vulnerable or poorly understood implementation
AI reviews code	Are its findings accurate and complete?	False positives or missed vulnerabilities
AI reports vulnerabilities	Is the issue real, exploitable, relevant, and reproducible?	Triage noise and speculative impact

The same model may participate in all three activities, but their risk profiles differ.

AI-Generated Code

When a model writes production code, organizations need to consider:

• code provenance
• security weaknesses
• licensing
• dependency choices
• developer understanding
• testing
• ownership

Linux's guidance reflects this principle by making the human contributor responsible for submitted AI-generated code.

AI Code Review

Here the model acts as a reviewer rather than an author.

The primary questions become:

• accuracy
• coverage
• context
• access to sensitive code
• reproducibility
• security impact
• interaction with existing controls

Organizations that need deeper validation can combine automated analysis with professional source code review rather than treating model output as the final decision.

AI Vulnerability Reporting

This is where operational consequences can become especially visible.

A model may produce a convincing technical explanation for something that is not actually exploitable.

If that report reaches a security team without validation, the organization still pays the triage cost.

Linux's current security guidance provides a useful example of that problem.

Is AI Code Review Secure Enough for Enterprise Use?

AI code review can be useful in enterprise environments, but “secure enough” depends heavily on deployment architecture and governance.

The model itself is only one part of the system.

Security leaders should evaluate at least five areas.

1. What Source Code Leaves Your Environment?

Sashiko's documentation warns that reviewing code with an external model may send patches, related commits, file contents, and repository context to the configured provider.

For public Linux code, that risk differs significantly from sending proprietary enterprise source code.

Before connecting an external model to a repository, determine:

• what files can be transmitted
• whether secrets may appear in context
• whether customer code could be included
• where data is processed
• how provider retention works
• whether submitted data can be used for model training
• which employees or services can trigger reviews
• whether highly sensitive repositories require different policies

Provider-specific answers should be verified against the actual agreement and current provider documentation.

Do not assume that an “enterprise” label automatically answers these questions.

2. How Much Repository Access Does the Reviewer Receive?

An AI reviewer may need broader context than the changed lines alone.

That can improve analysis, but it also increases exposure.

Apply least privilege.

A reviewing system should not automatically receive:

• deployment credentials
• production secrets
• unrestricted write permissions
• access to unrelated repositories

unless those permissions are genuinely required and properly controlled.

3. Can AI Findings Block a Merge Automatically?

A newly deployed AI reviewer should generally begin in an advisory role.

That allows the organization to measure the tool's behavior before giving it authority over production workflows.

During the pilot period, teams can assess:

• useful findings
• false positives
• missed defects
• developer acceptance
• triage workload
• remediation quality

More automated enforcement may later be appropriate for tightly defined scenarios, but it should be based on measured performance.

4. What Existing Security Controls Remain?

Do not remove proven controls simply because a new reviewer appears more capable.

A mature secure development workflow may still include:

• static application security testing
• software composition analysis
• secrets scanning
• compiler warnings
• unit tests
• integration tests
• manual review
• threat modeling
• dynamic testing
• penetration testing

The NIST Secure Software Development Framework, SP 800-218 provides a broader framework for integrating secure development practices throughout the software development lifecycle.

Organizations that need help integrating these controls can also review Hoplon Infosec's Secure SDLC Lifecycle Consulting.

5. Who Owns the Final Decision?

Every important finding needs an accountable owner.

A model cannot accept security risk on behalf of an organization.

Someone must decide:

• whether the finding is real
• whether it is exploitable
• how severe it is
• whether the proposed remediation works
• whether remaining risk is acceptable

The Linux approach makes this responsibility especially visible.

A human signs the contribution, not the model.

     

There is little reason to treat these as mutually exclusive choices.

They solve different parts of the security problem.

Capability	AI Code Review	SAST	Human Security Review
Large-scale automated coverage	Strong potential	Strong	Limited by time
Repeatability	Can vary	Usually consistent under the same configuration	Varies by reviewer
Contextual reasoning	Potentially useful	Limited	Often strong
Known-pattern detection	Useful	Strong	Strong
Business-logic understanding	Variable	Usually limited	Often strongest
False positives	Possible	Possible	Possible
False negatives	Possible	Possible	Possible
Natural-language explanation	Strong	Tool-dependent	Strong
Accountability	Cannot own risk	Cannot own risk	Human responsibility
Best role	Additional reviewer	Baseline automated analysis	Validation and contextual judgment

A good security program uses overlap deliberately.

One control may catch what another misses.

The objective is not to determine which method “wins.”

The objective is to improve the probability that serious weaknesses are identified before release without overwhelming development teams with noise.

For externally exposed applications, code analysis can also be paired with web application security testing and, where appropriate, penetration testing.

Seven Controls for Deploying AI Code Review Safely

1. Classify the Code Before Connecting a Model

Separate repositories by sensitivity.

For example:

• public open-source code
• internal utilities
• proprietary intellectual property
• regulated systems
• customer-specific applications

These repositories should not automatically receive the same AI access policy.

Document which categories can be reviewed externally.

2. Threat-Model the Reviewer

Treat the reviewing system as part of the software supply chain.

Ask:

• What data enters it?
• Which provider processes the data?
• What credentials does it hold?
• What can it read?
• Can it write?
• Can repository content influence its behavior?
• What happens if the integration is compromised?

3. Start in Advisory Mode

Run the reviewer without allowing it to automatically:

• approve code
• reject code
• merge changes
• deploy software

Measure results first.

A controlled pilot gives the organization evidence about whether the tool actually improves the development process.

4. Keep Independent Security Controls

Do not replace SAST, SCA, secrets scanning, security testing, or human code review merely because an AI reviewer can discuss multiple categories of defects.

Independent controls reduce dependency on one failure mode.

5. Require Human Accountability

A named developer or security reviewer should own important decisions.

Linux's human Signed-off-by model provides a useful example of clear accountability, even though enterprise teams may use different approval mechanisms.

6. Reproduce and Test Important Findings

For serious findings, require evidence.

Depending on the vulnerability, that may include:

• a failing test
• a reproducer
• a stack trace
• a vulnerable execution path
• proof that an authorization boundary can be crossed
• confirmation through another tool
• manual inspection

If the AI proposes a fix, test the fix separately.

7. Measure the Reviewer Continuously

Models change.

Prompts change.

Providers change.

Repositories evolve.

A benchmark performed during initial deployment does not permanently establish future performance.

Track the system over time.

AI Code Review Security Decision Matrix

Question	Lower-Risk Condition	Warning Sign
Does proprietary code leave the organization?	Approved provider and documented data path	Retention or training behavior is unclear
Does the reviewer have write access?	Read-only unless clearly required	Broad repository or deployment permissions
Are important findings independently verified?	Human or test confirmation required	AI judgment accepted automatically
Are existing scanners retained?	Multiple independent controls remain	AI replaces SAST, SCA, or testing
Is performance measured internally?	Controlled validation dataset	Vendor benchmark accepted as proof
Is there an accountable owner?	Human reviewer owns the decision	Responsibility attributed to the model
Are model changes controlled?	Changes trigger reassessment	Models change without validation

A security team that cannot answer these questions clearly is probably not ready to make an AI reviewer a production security gate.

A broader cybersecurity gap assessment can help identify where AI-assisted development controls fit into an organization's existing security program.

How Should You Measure AI Code Review Performance?

Do not evaluate an AI reviewer by the number of comments it produces.

Measure useful outcomes.

Valid Finding Rate

Of the findings reviewed by qualified humans, how many are confirmed?

This helps measure triage quality.

Known-Defect Detection

Create or select a controlled dataset containing known weaknesses.

Measure how many the system identifies.

Do not describe that result as a universal accuracy rate. It only describes performance on that particular dataset.

False-Negative Analysis

When another tool or reviewer later finds an important vulnerability, check whether the AI system had already evaluated the same code and missed it.

Missed defects can reveal systematic blind spots.

Triage Time

Measure how long developers and security engineers spend validating findings.

A technically impressive system can still create a net productivity loss if its output requires excessive investigation.

Fix Quality

If the reviewer proposes remediation, test whether:

• the underlying defect is actually removed
• tests continue to pass
• expected functionality remains intact
• no new weakness is introduced

Repeatability

Run selected patches through the system multiple times under controlled conditions.

Model-based systems can be probabilistic, so identical inputs may not always produce identical outputs.

Security Coverage

Track which weakness categories the system actually identifies in your environment.

Do not assume a broad security prompt performs equally well across:

• authentication
• authorization
• injection
• cryptography
• memory safety
• concurrency
• business logic
• secrets exposure
• configuration
• dependency risk

When Human Secure Code Review Still Matters

Human review becomes especially important when understanding the security impact requires business or architectural context that is not fully represented in the patch.

Examples include:

• unusual authorization rules
• financial transaction logic
• tenant isolation
• trust boundaries
• cryptographic design
• safety-critical workflows
• interactions across several systems
• undocumented historical architecture

A qualified reviewer can ask a question automated systems may struggle to answer reliably:

Even if this code behaves exactly as written, is that behavior safe for this system and threat model?

That is one reason independent source code security review can remain valuable even when development teams already use automated tools.

When Should an Organization Seek Professional Help?

Professional assessment becomes useful when a team cannot confidently answer questions about:

• source-code exposure
• AI provider boundaries
• secure development controls
• reviewer quality
• human accountability
• CI/CD integration
• threat modeling
• validation criteria
• security testing coverage
• acceptable residual risk

Organizations at an earlier stage can use a broader cyber security assessment to understand gaps in their current security posture.

Teams introducing AI across engineering and security functions may also need ongoing security leadership and governance. Hoplon's Virtual CISO services are relevant where organizations need structured security strategy and risk management support.

The objective should not be to prevent developers from using useful tools.

It should be to ensure those tools enter the development lifecycle with clear boundaries, verification, and measurable security controls.

Frequently Asked Questions

Can AI Code Review Replace Human Reviewers?

There is not enough evidence to support replacing human secure code review across all software environments.

AI review can help identify defects at scale, but it can also miss problems, generate false positives, misunderstand threat models, or suggest incorrect remediation.

Human accountability and contextual review remain important.

Is Sashiko Replacing Linux Kernel Maintainers?

No.

Sashiko is designed to assist review rather than take ownership of the Linux development process.

Its own documentation describes model output as probabilistic.

Does Sashiko Really Detect 53.6% of Bugs?

Sashiko's maintainers report that figure from their retrospective testing using Gemini 3.1 Pro against a specific set of historical Linux kernel commits.

It should therefore be described as a Sashiko-reported benchmark, not a general AI code-review accuracy statistic.

Is AI Code Review the Same as SAST?

No.

Traditional static application security testing analyzes source code or related representations using defined analysis techniques, rules, and program-analysis methods.

Model-based review generates findings through probabilistic reasoning over the supplied code and context.

Their capabilities can overlap, but they operate differently.

Is It Safe to Send Private Source Code to an AI Reviewer?

It depends on:

• the provider
• deployment architecture
• contract
• data-retention terms
• training policies
• access controls
• source-code sensitivity

These conditions should be verified before proprietary repositories are connected.

Should AI-Generated Security Reports Be Trusted?

They should be investigated, not automatically trusted.

Important findings should be validated through technical evidence, reproducible behavior, testing, or qualified human review.

Final Takeaway

The Linux debate does not prove that AI has replaced secure code review.

It demonstrates something more practical.

A specialized AI reviewer can identify meaningful defects, including issues that may have passed previous review. At the same time, false positives, probabilistic behavior, poor threat interpretation, unverified reports, and additional triage workload remain real limitations.

Linux's approach provides a useful enterprise lesson because it combines AI adoption with human accountability.

The technology may change quickly.

The basic controls remain familiar:

Know what data the tool can access, restrict its permissions, verify important findings, test proposed fixes, retain independent security controls, measure performance, and keep a human responsible for the final decision.

That is a practical approach to AI code review security.

Sources and Methodology

This article was prepared using publicly available technical documentation and primary-source material.

The analysis primarily used:

• Linux kernel development documentation
• Linux kernel security-reporting guidance
• Sashiko's public project documentation
• NIST secure software-development guidance
• current reporting for the context of Torvalds's July 2026 comments

Hoplon Infosec did not provide original testing data for Sashiko or another AI code reviewer for this article.

The 53.6% detection figure and approximate 20% false-positive range are presented specifically as Sashiko's published measurements, not independently verified Hoplon findings.

References

1. Linux Kernel - AI Coding Assistants
2. Linux Kernel- Security Bugs
3. Sashiko Project Repository
4. NIST SP 800-218 - Secure Software Development Framework
5. Linux Kernel - Threat Model