Git history rarely provides a complete record of AI involvement. Co-author trailers and bot identities identify some commits, but developers can modify generated code before committing it. Other tools leave no recognizable signature.

An audit therefore needs two sources of information: available commit metadata and the history of AI tool adoption within each team.

Start with four security-sensitive areas:

• Authentication and identity management
• Data access and tenant isolation
• Input handling and validation
• External API calls and integrations

Establish when each team adopted AI coding assistants and which tools it uses. A first-pass repository search can identify commits carrying Co-authored-by trailers. Git history can then be reviewed from the adoption date onward, including changes without AI attribution.

For example, the following command lists commits containing co-author metadata:

git log --all --format="%H %ad %s%n%b" --date=short \
  --grep="Co-authored-by:"

Use the results to identify tagged contributions. Extend the review to every change in the four risk areas since the adoption date.

The provenance review should produce a scope register containing repositories, folders, date ranges and the security-sensitive components they contain. That register guides the remaining four layers.

NuGet audit identifies packages with known vulnerabilities during package restore. It uses vulnerability information from configured audit sources, including the GitHub Advisory Database.

The .NET 8 SDK introduced NuGet auditing. For projects targeting .NET 10 or later, NuGetAuditMode defaults to all, which includes transitive dependencies. Earlier target frameworks default to direct dependency auditing unless transitive coverage is explicitly enabled.

Microsoft documents warning codes NU1901 through NU1904:

• NU1901: Low severity
• NU1902: Moderate severity
• NU1903: High severity
• NU1904: Critical severity

A project can treat high and critical findings as build errors:

  all
  $(WarningsAsErrors);NU1903;NU1904

This configuration provides a useful baseline for projects targeting earlier frameworks that need explicit transitive dependency auditing.

Source: Microsoft Learn: Auditing package dependencies for security vulnerabilities.

NuGet audit has a defined scope. It checks known vulnerabilities in the dependency graph. It does not determine whether a package is necessary, trustworthy or appropriate for the application.

AI assistants can recommend packages that do not exist in the registry. If an unrelated publisher registers the suggested package name, a developer who follows the generated installation command without verification can introduce a malicious dependency.

Review every PackageReference added since AI tool adoption. Check:

• Publisher identity and package ownership
• Source repository and release history
• Package maintenance and recent activity
• Dependency requirements and transitive packages
• Whether an existing .NET framework API already provides the required functionality

Maintain an approved-package register with reviewer names, review dates and a documented exception process. This gives the engineering team a record of which dependencies have been evaluated and why they were accepted.

GitGuardian's State of Secrets Sprawl 2026 report counted approximately 28.65 million new hardcoded secrets on public GitHub in 2025, a 34% year-over-year increase. Secrets associated with AI services increased by 81%.

The report also measured a 3.2% secret-leak rate for Claude Code co-authored commits, compared with a 1.5% baseline across public GitHub commits. The comparison concerns one identifiable coding tool and does not establish that the tool alone caused the difference. GitGuardian also highlights the role of developers in deciding which changes reach public repositories.

The report identifies another important gap: approximately 28% of secrets incidents originate outside code repositories, including collaboration and productivity tools such as Slack, Jira and Confluence.

Source: GitGuardian: State of Secrets Sprawl 2026.

An audit needs to cover credentials in source code, configuration files, deployment settings and relevant development-tool history.

Start by scanning each repository's full Git history. Removing a credential from the latest commit does not remove it from earlier commits.

For Azure-hosted applications, move supported secrets into Azure Key Vault and use Microsoft Entra managed identities where the target service supports them. Managed identity removes the need to maintain certain application credentials, while Key Vault provides centralized secret storage and access controls for credentials that remain necessary.

Credential rotation requires a separate remediation step. Moving an exposed API key or connection string into Key Vault does not invalidate the original credential.

For each exposed secret:

1. Identify the affected service and dependent applications.
2. Revoke or rotate the exposed credential.
3. Update dependent services and deployment configurations.
4. Validate that the previous credential no longer works.
5. Review logs and access history for possible misuse.

GitGuardian's report also found that 64% of credentials detected as valid in 2022 remained active in January 2026. That finding highlights the importance of completing remediation after detection.

For Microsoft 365 environments, Preparing Microsoft 365 Data for AI provides additional context on data access and preparation requirements. The article on Building AI Agents on Azure also covers Key Vault and managed identity in agent architectures.

Veracode's research identified cross-site scripting and log injection among the weakest areas of generated code. Both deserve focused attention in .NET applications.

For ASP.NET applications, review output encoding in Razor views and API responses. Pay particular attention to:

• Calls to Html.Raw, which bypass Razor's normal HTML encoding
• User-controlled values included in HTML or JavaScript output
• Log statements that incorporate untrusted input
• SQL queries assembled through string concatenation
• Deserialization and external input-processing paths

Structured logging with message templates keeps variable values separate from the template itself. For example:

logger.LogWarning(
    "Invalid login attempt for user {UserId}",
    userId);

Avoid constructing log messages by concatenating untrusted input into the message template. Review the logging provider and output format as well, because structured logging alone does not guarantee safe handling of every value.

Raw SQL requires similar scrutiny. Entity Framework Core's FromSqlRaw can introduce SQL injection when untrusted values are concatenated into SQL text. FromSqlInterpolated parameterizes interpolated values when used through the intended API. Review the actual overloads and data flow rather than relying on method names alone.

CodeQL provides another layer of coverage. GitHub supports C# threat models, allowing teams to configure additional sources of untrusted data for analysis. The threat-model feature is documented as public preview, so availability and behavior should be checked against the current GitHub documentation.

Source: GitHub Docs: Editing your configuration of default setup.

.NET code analysis provides additional checks for code quality, reliability, performance and usage patterns. Analysis is enabled by default for projects targeting .NET 5 and later. The default set of build warnings is limited, so security reviews should consider enabling additional rules.

Setting AnalysisMode to All enables the available analyzer rules as build warnings, with documented exceptions for certain legacy rules. The -warnaserror build option can then turn analyzer warnings into build failures.

For example:

  All

A team can also use AnalysisLevel to select a predefined rule set, such as latest-all.

Sources:

●      Microsoft Learn: Code analysis in .NET

●      Microsoft Learn: Configure code analysis rules

Existing applications often have a substantial analyzer backlog. Establish a baseline, prioritize security-sensitive components and introduce build-failing rules in stages. Apply the agreed enforcement policy to newly introduced findings from the beginning.

Automated analysis still has limits. A scanner cannot determine every business authorization rule from source code alone. It may identify an input path without understanding which tenant owns the record or which role is allowed to modify its state.

Human reviewers should examine low-confidence findings and business logic that depends on application-specific authorization requirements. Compare implementation behavior with the documented security model and test the relevant paths.

A clean scan confirms that the configured checks passed. It does not establish that every application vulnerability has been identified.

GitClear's 2025 AI Code Quality research analyzed 211 million changed lines of code from 2020 to 2024. Its findings showed that 2024 was the first year in the dataset when copy-pasted lines exceeded moved lines. Blocks containing five or more duplicated lines increased eightfold, while moved lines, used as a proxy for refactoring, fell by 39.9%.

Source: GitClear research, reported by DevClass, February 20, 2025.

Duplicated code increases the maintenance burden when a security fix needs to reach multiple implementations. A patch applied to one copy leaves other copies unchanged until someone identifies and updates them.

The audit should search for repeated blocks within the security-sensitive areas identified during provenance review. Rank duplication clusters according to:

• The functionality they implement
• The security sensitivity of the affected code
• The number of copies across the repository
• The teams or components responsible for maintenance

Some repetition is intentional. Similar code in separate platform-specific implementations, for example, can reflect legitimate architectural requirements. Reviewers should distinguish those cases from duplicated authentication, validation, authorization or data-access logic.

Consolidating risky duplication into shared components requires architectural judgment and repository-level experience.

Softwarium engineers built a cross-platform macOS and Windows application in C# with Xamarin for a cybersecurity company, sharing approximately 80% of the code across both platforms. The shared architecture allowed changes to common functionality to reach both platforms through a single implementation.

Engineering teams with a prioritized list of duplicated components can use Softwarium's .NET development services to assess the consolidation work and implement the required changes.