How to Audit Source Code for Security and Compliance

The audit deadline is close. Engineering has merged a large feature, procurement wants confirmation that third-party components are approved, and the compliance team needs evidence that security controls were implemented. A scanner produces a long findings list, but it doesn't explain whether the most important business process can be bypassed, whether an AI-generated pull request follows the approved design, or how each issue relates to a documented threat.

That's the practical problem with many attempts to audit source code. Teams collect alerts, review selected files, and produce a report, yet struggle to show why the scope was chosen, which risks were tested, and whether remediation changed the control that was supposed to protect the system. A defensible audit is more than a search for defects. It's a chain of evidence connecting code, dependencies, architecture, threats, decisions, and proof of correction.

Why Modern Source Code Audits Go Beyond Your Own Code

A review often starts with a familiar request: inspect the application repository before release. The request sounds narrow, but the application may depend on package registries, inherited libraries, generated code, build actions, container images, infrastructure definitions, and transitive dependencies that developers never opened directly.

That broader boundary matters. A 2020 industry analysis of open-source security reported that 99% of commercial codebases contained at least one open-source component, with an average of 445 open-source components. It also found that open source represented 70% of audited code, up from 60% in 2018 and nearly double the 36% share reported in 2015. Those figures don't mean every dependency is exploitable, but they do change what an auditor must examine.

The dependency graph is part of the product

The same analysis reported that 75% of audited codebases contained open-source components with known security vulnerabilities, while 49% contained high-risk vulnerabilities. It also found that 91% contained components more than four years out of date or with no development activity during the previous two years. These are not reasons to ban open source. They're reasons to verify provenance, patch status, license obligations, maintenance activity, and how a package enters the build.

The audit should therefore answer practical questions:

• What is deployed? Compare lockfiles, manifests, generated artifacts, and production build outputs.
• Who maintains it? Record package versions, sources, maintainers, and update history where available.
• What does it inherit? Inspect transitive dependencies instead of stopping at the direct package list.
• Can the team remediate it? A finding without an owner, upgrade path, compensating control, or accepted risk isn't audit-ready.

Complexity makes a superficial review even less credible. A 2026 open-source risk analysis from Black Duck reported that the average audited codebase contained more than 84,000 files, which it said had quadrupled in five years. The same analysis reported that mean open-source vulnerabilities per codebase had more than doubled to 581. A reviewer can't manually read every line with equal attention. Scope and prioritization must follow exposure and consequence.

What success looks like

A point-in-time review can be useful for a release, acquisition, certification milestone, or major architectural change. It becomes weak when nobody preserves the assumptions behind it. A living audit keeps the threat model, approved design decisions, dependency inventory, scan configuration, manual review notes, exceptions, and remediation evidence connected as the system changes.

For delivery teams building that operating rhythm, a practical guide for dev teams can help establish ownership and review habits around the engineering work itself. The security outcome is straightforward: audit success means traceable evidence, not an impressive bug count. An auditor should be able to follow a finding from risk statement to code location, approved decision, fix, retest, and residual risk.

Scoping Your Audit for Risk and Compliance

A defensible scope starts before any tool runs. Begin with the product boundary, then map the data and business functions that cross it. Include the repositories, services, scripts, deployment definitions, generated artifacts, and third-party components that can alter confidentiality, integrity, availability, or regulatory obligations.

Write the scope as an explicit statement rather than a repository link. For example, identify the customer-facing service, its authentication path, administrative functions, data-processing workers, deployment configuration, and external integrations. State what isn't included and why. An exclusion without a rationale looks like an oversight, even when it was deliberate.

Four decisions define the boundary

Product boundary. List the repositories and deployed services that implement the feature under review. Add infrastructure-as-code, CI workflows, migration scripts, configuration templates, and code generation inputs when they influence runtime behavior or release integrity.

Data sensitivity. Classify the data handled by each path. Authentication, authorization, payment, health, personal, encryption-key, and administrative workflows deserve deeper inspection than low-impact presentation code. Follow data from ingress through storage, queues, logs, exports, and deletion.

Regulatory driver. Map the review to the control objective, not just the framework name. SOC 2 and ISO 27001 evidence often needs to show ownership, review activity, change control, risk treatment, and retained proof. A scanner export alone rarely demonstrates how the team made and enforced a security decision.

Third-party dependency mapping. Include direct and transitive dependencies, package metadata, license information, vendored code, build plugins, and generated outputs. If a component can enter the shipped artifact, it belongs in the inventory or requires a documented exclusion.

Prioritize the paths an attacker can abuse

Don't give every file the same review depth. Rank components by internet exposure, privilege, sensitive data access, transaction authority, cryptographic responsibility, and change magnitude. A small authorization helper may deserve more manual attention than a large internal utility because its failure changes who can perform an action.

The growth of codebases reinforces this approach. The Black Duck analysis reported a median file-count increase from 16,082 to 21,672 in one year, a 35% jump, and reported license conflicts in 68% of codebases. Those findings support a practical conclusion: scope must cover both security and compliance exposure, but review intensity should follow risk.

Record the commit or release under review, the dependency snapshot, tool versions, scan configuration, reviewers, assumptions, exclusions, and acceptance criteria. That record turns “we scanned the repository” into a reproducible audit plan.

Automated Scanners Versus Manual Review and When to Use Each

Automated analysis is excellent at coverage and repeatability. SAST can identify recognizable insecure patterns in first-party code. SCA can identify vulnerable or outdated dependencies and license concerns. Secrets scanners can flag credentials and tokens that match known formats. These tools belong in the workflow because humans shouldn't spend scarce review time rediscovering predictable patterns across every pull request.

They also have hard limits. A scanner generally can't determine whether a refund endpoint permits an unauthorized state transition, whether two individually safe services combine into an unsafe privilege path, or whether a cryptographic design protects the right asset. It may flag a suspicious function without understanding the validation performed elsewhere, creating triage noise. It can also miss a design flaw because the implementation is syntactically valid and uses approved APIs.

The gap is especially important for AI-generated code. Vendor-neutral guidance on conducting a successful code audit notes that manual review remains necessary for authentication-bypass logic, weak cryptographic key handling, architecture soundness, and compliance or provenance concerns in AI-generated pull requests, while automation mainly covers known patterns and dependency issues. Reviewers need to ask what the code is intended to guarantee, not just whether it resembles a known vulnerability pattern.

Use each technique for its comparative advantage

A useful rule is to automate the broad pass and reserve human attention for decisions. Teams can also use an automated security review workflow to reduce repetitive checks, provided the output remains explainable and tied to an owner.

Don't treat manual review as a ceremonial sign-off. Give reviewers a risk-based slice, the relevant architecture, abuse cases, expected invariants, and a clear question to answer. Don't treat scanner output as a backlog either. Suppress duplicates, explain accepted risks, tune rules, and require evidence before closing a finding.

Running the Audit Workflow From Setup to Report

A reliable audit follows a controlled sequence. Start by preserving the environment and the exact artifact under review. Record the repository revision, dependency lockfiles, build instructions, deployment configuration, generated code inputs, scan rules, and tool versions. Isolate credentials and avoid connecting an audit environment to production unless the test plan explicitly requires it.

Establish context before collecting alerts

Review the architecture and threat model before interpreting scanner results. Identify trust boundaries, privileged operations, external inputs, secrets, sensitive stores, asynchronous workflows, and failure modes. If documentation is incomplete, reconstruct the security-relevant flow from routes, handlers, data models, service permissions, deployment definitions, and tests, then mark assumptions clearly.

Configure SAST, SCA, secrets detection, license checks, and custom rules against the scoped artifact. Keep the raw outputs, but don't send them directly to executives or auditors. Normalize duplicate findings, map them to assets and threats, and distinguish confirmed issues from hypotheses that require validation.

Manual inspection works best when paced. A published source-code audit methodology recommends environment setup, architecture review, threat modeling, static analysis, manual review, and a remediation report before sign-off. It associates inspection rates around 100 to 200 lines of code per hour with effective defect finding, while rates above 200 lines per hour reduce review effectiveness; the cited study found more than half of code defects through reviews at this pace. See the published audit methodology for the underlying workflow and review-rate discussion.

Keep review notes useful

Don't ask reviewers to read an undifferentiated diff. Assign focused questions:

• Input handling: Can untrusted data reach a sensitive operation without the required validation?
• Authorization: Does every state-changing action verify the actor, resource, tenant, and permitted transition?
• Secrets and cryptography: Are keys protected, rotated, scoped, and used for the intended purpose?
• Resilience: What happens when dependencies fail, queues replay messages, or requests arrive out of order?
• AI provenance: Which code was generated or materially transformed, and what human review verified its assumptions?

Capture file paths, symbols, line ranges, reproduction steps, affected assets, threat references, severity rationale, and suggested remediation. A useful finding states the violated security property and the evidence that proves it. “Potentially insecure code” isn't enough for an engineer to fix or for an auditor to validate.

The final report should separate confirmed findings, observations, accepted risks, exclusions, and unresolved questions. Assign owners and due dates through the team's normal system, then retest the exact change. For teams organizing evidence around compliance workflows, the SOC2Auditors software page provides relevant context on software and audit operations.

Tracing Findings Back to Threat Models and Design Decisions

A finding becomes materially more useful when it answers four questions: Which threat does this represent? Which design decision should have prevented it? Which control or policy governs that decision? What evidence shows the correction works?

Consider an authorization defect in an administrative endpoint. The code location is only the starting point. The associated threat may be privilege escalation. The governing design decision may require server-side authorization against the target resource and tenant. The policy may require every privileged state change to enforce that decision. The remediation evidence may include the patch, a regression test, a pull-request review, and a retest result.

Build a finding record that preserves reasoning

Use a consistent record with linked identifiers rather than prose scattered across tickets and documents:

1. Asset and change: Repository, service, commit, release, and affected component.
2. Threat and abuse case: The actor, capability, target, and harmful outcome.
3. Design requirement: The approved security property, architecture decision, or control.
4. Implementation evidence: Relevant code, configuration, tests, and review decisions.
5. Disposition: Remediation, compensating control, accepted risk, or justified exclusion.
6. Verification: Retest result, reviewer, date, and remaining limitations.

This structure helps when the code changed but the design document didn't. A living security context should update from repositories, planning artifacts, service metadata, and pull requests. Where formal documentation is thin, reconstruct the context from implementation and label reconstructed conclusions as assumptions that require owner confirmation.

The evidence must also show what the team decided not to fix. An accepted risk should identify the affected threat, rationale, owner, expiry or review condition, and compensating controls. Otherwise, a “false positive” label can hide an unexamined design gap.

Human review needs structured disagreement

Reviewers are not complete vulnerability detectors. A controlled security code-review study reported that none of the subjects found all confirmed vulnerabilities, and that false-vulnerability reports were significantly correlated with valid findings. In other words, a reviewer who finds real issues may also create noise. Separate confirmation from discovery, invite a second perspective for high-impact paths, and record uncertainty instead of forcing premature certainty.

Research summarized in the same Berkeley report found that only about 15% of code-review comments identify possible defects, while the median time to collect all sign-offs was about 24 hours, with some reviews taking days or weeks. These figures are not a reason to maximize comments. They're a reason to make review intent explicit and preserve the security decisions that matter.

Teams that need a repeatable threat-modeling process can use structured threat and decision records to connect findings to the control they test. The audit then demonstrates more than activity. It demonstrates that the organization can explain why a control exists, where it is implemented, and how it knows the implementation remains effective.

Making Audits Continuous and Audit Ready

A formal audit still has a place. It can support a release, certification, acquisition, or major change. But treating it as the only moment of scrutiny guarantees drift between reviews. Repositories change, dependencies update, teams adopt new services, and AI-assisted coding introduces implementation decisions that weren't present when the original threat model was approved.

The operational answer is continuous evidence. Put lightweight checks at pull-request creation, require deeper review for high-risk changes, and refresh the relevant threat model when a change crosses a trust boundary or alters a security property. A recent discussion of source-code trends describes the shift toward pre-merge gates, continuous DevSecOps integration, and AI-assisted review, while identifying the harder problem as operationalizing evidence across the delivery lifecycle rather than treating code audit as a periodic checkpoint.

Make the control visible in the workflow

A sustainable model doesn't ask security to attend every meeting. It places context where work happens and escalates only decisions that need expertise.

• Pre-merge gates: Check changed assets, dependency updates, secrets, required policies, and design references before approval.
• Risk-based routing: Send authentication, cryptography, tenant isolation, payment, health-data, and administrative changes to focused review.
• AI guardrails: Require generated code to identify its source or transformation, inherit the applicable threat context, and pass the same policy and human checks as authored code.
• Evidence retention: Store scan versions, rule configurations, reviewer decisions, exceptions, remediation commits, and retest results.
• Threat-model refresh: Revisit assumptions when APIs, data flows, trust boundaries, providers, or deployment privileges change.

Your application security posture should reflect current implementation, not a document that describes an earlier system. Tools can enforce required checks, but owners still need to decide whether a finding is valid, whether a design is acceptable, and whether residual risk is understood.

The practical checklist is short:

1. Scope the deployed product and its dependency graph.
2. Preserve the exact artifact, tools, rules, and assumptions.
3. Combine automated coverage with targeted manual review.
4. Tie each finding to a threat, design decision, and policy.
5. Retest fixes and retain proof.
6. Trigger review when risk-relevant changes occur, not only before an annual audit.

DevArmor connects pull-request security review and implementation verification to the threat models, design decisions, and policies behind your application. Use DevArmor to create traceable review evidence for code changes, including AI-assisted work, and keep audit context current across the delivery lifecycle.