Secure Coding, SDLC, Application Security Policy¶

Version history¶

Version Number	Date	Description	Created By	Approved By
0.1	23/Jan/2024	Initial Copy	[Name] [Name]
0.2	18/Jun/2024	Approved	[Name] [Name]	[Name]
0.3	28/Aug/2026	Knowledge kernel, AI/agents, control alignment	Knowledge steward	[Name]

Code Development & Secure Coding Practices¶

Code Quality and Review Process¶

Static Code Analysis: SonarLint is used during local development to ensure code quality and detect potential issues early.

Pull Request Reviews: A SonarQube analysis report is generated for all pull requests based on the commits, allowing reviewers to check for code quality and potential security vulnerabilities.

Standardized Reviews: Pull request reviews are standardized to minimize the risk of security breaches and ensure consistent code quality.

Code Quality Metrics: SonarQube analysis is run on the development branch, with the goal of maintaining zero code smells and security breaches.

Authentication and Access Control¶

Multi-Factor Authentication (MFA): MFA is enabled for developers accessing Google Cloud Platform (GCP) environments to enhance security.
Secure Storage of API Keys: API keys are stored in a secure vault, and developers are granted read-only access as needed.
Controlled Database Access: Developers are given access only to the development database, which is protected with SSL files and IP restrictions. Access is granted through proper email communication involving all relevant parties.

Deployment and Container Security¶

Service Deployment: Service deployment is handled by the Site Reliability Engineering (SRE) team using Terraform, with restricted access to developers.
Docker Security: Docker images undergo vulnerability detection to ensure they are secure before being used.
Trusted Resources: Only trusted libraries and images are used in the development process to minimize security risks.

Software Development Life Cycle¶

Development Process¶

Branch Management: Development is conducted on private branches by developers, identified by Jira ticket IDs.
Pull Requests and Merging: Pull requests are raised against release or feature branches for each sprint. Once approved, these branches are merged and deployed to the Quality Assurance (QA) environment for testing.
Testing and Deployment: After successful testing and receiving approval, the code is merged into the development branch and subsequently released to production.

Detailed Workflow¶

Requirement Analysis:
Collect and analyze requirements.
Document requirements and get approval from stakeholders.
Design:
Create high-level and detailed design documents.
Review and approve design documents.
Implementation:
Write code based on the design documents.
Use SonarLint for local code analysis.
Perform unit testing and static code analysis.
Code Review:
Create pull requests for peer review.
Conduct standardized code reviews with SonarQube analysis.
Testing:
Deploy code to the QA environment.
Conduct integration, system, and user acceptance testing.
Fix identified issues and retest.
Deployment:
Merge code into the development branch after testing.
SRE team deploys the code to the production environment using Terraform.
Maintenance:
Monitor the production environment for issues.
Perform regular updates and patch vulnerabilities as needed

6.

7.

Normative SDLC, secure coding, and application security requirements (v0.3)¶

The following requirements supersede tool-specific narrative above. Named tools (for example SonarQube, GCP, Jira, Terraform) are examples of current implementations, not the control. An equivalent control with evidence is acceptable.

Must

Development, test, and production environments shall be separated. Production credentials shall not be issued to developer workstations or coding agents.

Must

Every merge to a protected default branch requires independent human review. The author, including an agent that drafted the change, shall not self-merge.

Must

Required pipeline gates before merge: secret scan (every commit); software composition analysis; static application security testing; unit tests. Fail on critical/high unless a recorded exception with owner, compensating control, and expiry exists.

Must

Dynamic testing or an equivalent pre-release security test is required before production. Every production deploy shall be logged (who, SHA, when).

Must

Secure coding principles shall be applied to in-house, outsourced, open-source, and AI-generated code (ISO 27001 A.8.25–A.8.29). Agent frameworks are in scope of secure coding.

Must

Application security requirements shall be defined for each system. OWASP ASVS (pinned version in org.yaml) is the default verification catalogue; the org ASVS level is the floor.

Should

Threat modelling or an equivalent design review is performed for new internet-facing or privileged services.

Must

Secrets shall live in a vault or platform secret store, not in git, wikis, tickets, or prompts. Default passwords shall be rotated on first use.

Must

Infrastructure and application changes follow the Change, Rollback and Release procedure. Emergency changes require retroactive review within 24 hours.

Must

Coding agents may propose patches, tests, and threat-model drafts as candidates. They shall not waive gates, accept risk, or mark knowledge approved.

Must

Compiled agent skills and CI gate lists shall be regenerated when a must procedure is approved or withdrawn. Stale skills are non-compliant.

Should

Language and platform hardening checklists apply only where the org tech profile says that language or platform is in use.

Software agents, bots, service accounts, CI jobs, and coding assistants are identities. They are in scope of this policy wherever people are.

Every retrieve or use of organizational knowledge or classified data requires a verified identity, a stated purpose, and a classification ceiling. Missing purpose is deny.

AI may extract, draft, rank, or propose. AI shall not approve access, classify or reclassify information, set reuse rights, waive a control, merge to a protected branch, or treat search ranking as truth.

Approved reusable knowledge is a governed claim with source, owner, lifecycle, applicability, and limitations. Raw chat, tickets, and scanner output are not approved knowledge.

Embeddings, summaries, caches, and compiled agent skills are derivatives. Withdrawal, reclassification, or destruction of a source shall propagate to derivatives.

Secrets, credentials, production data dumps, and Restricted (including client/PHI) material shall not be pasted into public generative-AI services or stored in vector indexes unless an authorized path and agreement exist.

HIPAA-regulated PHI is out of default scope. Enable the HIPAA pack and a business-associate path before any PHI is processed by agents or knowledge indexes.

Change to a must procedure (including knowledge used by agents) is a change under the Change / Release procedure and SOC 2 CC8.1. Agents cannot approve that change.