Code Security Scanning Policy¶

Classification: Internal
Document status: Effective
Version: 1.2
Owner: Management / Security Owner
Review cycle: Annual; interim revision upon material change to supported languages, repositories, or scanning platforms

Document control¶

Role	Name
Prepared by	Management / Security Owner (Cloudnaut)
Reviewed by	Nidhi Jain (third-party reviewer)
Approved by	Sandeep AC

Revision history¶

Version	Date	Summary	Reviewed by	Approved by
0.9	2021-03-14	Draft for third-party review prior to first effective release.	Nidhi Jain (third party)	—
1.0	2021-06-18	Initial effective release.	Nidhi Jain (third party)	Sandeep AC
1.0	2024-03-11	Scheduled annual review; clarifications and cross-references (retained at version 1.0).	Nidhi Jain (third party)	Sandeep AC
1.1	2026-05-19	Sonar SAST, CI/CD integration, SAST vs SCA clarity for SSDLC alignment.	Nidhi Jain (third party)	Sandeep AC
1.2	2026-05-19	Mandatory continuous scanning on engagement repositories; merge-blocking gates.	Nidhi Jain (third party)	Sandeep AC

Purpose¶

This policy defines mandatory security scanning for code, dependencies, and repository configuration on every customer engagement repository Cloudnaut provisions or maintains. Scans run continuously in CI/CD and on pull requests per the Secure Software Development Lifecycle Policy.

Scope¶

This policy applies to application source, infrastructure-as-code, scripts, manifests, lockfiles, and repository settings under Cloudnaut control for customer engagements.

Policy¶

Every engagement repository uses the standard scan stack below at onboarding, integrated into CI/CD workflows. When a customer contract requires a different approved tool (for example an enterprise scanner mandated by the prime), that tool substitutes for the named product but does not remove the requirement for continuous SAST and SCA in the merge path.

Standard tooling:

GitHub Dependabot — SCA on GitHub-hosted repositories.
Snyk — SCA (dependencies, lockfiles; IaC or container when configured).
SonarQube / SonarCloud — SAST on application source.

Tooling roles (Dependabot, Snyk, and Sonar)¶

Software composition analysis (SCA)¶

GitHub Dependabot: enabled by default on Cloudnaut-managed GitHub engagement repositories—dependency and security alerts and update pull requests on supported ecosystems.
Snyk: SCA integrated into CI/CD—continuous scanning of declared dependencies, lockfiles, and manifests; known vulnerabilities, upgrades, and license issues. IaC or container analysis when the project configuration includes those surfaces.

Static application security analysis (SAST)¶

SonarQube / SonarCloud: SAST integrated into every engagement pipeline—pull-request and protected-branch analysis for security-relevant code patterns (per enabled quality profile). Sonar does not replace peer review, threat modeling, or manual QA.

What these tools do not replace¶

Dependabot, Snyk, and Sonar do not replace structured design review, threat modeling, pre-deployment secure-configuration review, or customer-required tools. They enforce continuous visibility together with branch protection and peer review.

CI/CD integration¶

Onboard repositories with Dependabot, Snyk, and Sonar (or documented customer-mandated equivalents) before substantive development.
Run scans on every pull request and protected-branch pipeline—findings surface before merge.
Configure quality gates so failed checks block merge on agreed severity thresholds until remediation or written customer-approved risk acceptance.
Align pipeline credentials with the Engagement Access Isolation Policy.

Process¶

Maintain continuous SAST and SCA per CI/CD integration above—disabling scans on an active engagement repository requires management approval and compensating controls.
Review findings in the merge and release path prior to customer delivery.
Remediate material findings or document risk acceptance with customer or engagement management approval when deferral is justified.
Known critical issues are not delivered as final customer-facing releases unless the customer explicitly accepts the residual risk in writing.

Records¶

Typical evidence includes tool dashboards, exported reports, CI job logs, pull requests that remediate findings, quality-gate configuration screenshots, and risk acceptance records.