ISO 27001 A.8.4: Access to Source Code

Quick Reference (60 Seconds)

Bottom Line: Source code is your organization's intellectual property. It contains business logic, security controls, API keys, and potential vulnerabilities. Unauthorized access to source code can lead to IP theft, security bypasses, and competitive disadvantage. This control ensures source code is protected with the same rigor as production data.

What the Control Asks For

In short:

ISO 27001:2022 Annex A 8.4 asks organizations to control who can view and change source code, together with the build tools and code libraries behind it.

Do you need this control?

A.8.4 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you develop software or keep source code, development tools or software libraries. An organisation that only buys software may exclude it with that reason.

What ISO 27002:2022 Adds

27002 8.4 (paraphrased) says access to source code and associated items (designs, specifications, verification and validation plans) and to development tools (compilers, builders, integration tools, test platforms and environments) should be strictly controlled, preferably by keeping code centrally in a source code management system.

Read and write access can differ by role. Read access can be provided broadly inside the organisation (for example shared components or inner-source), and broadly to open-source and third-party code repositories, while write access is limited to privileged personnel or designated owners.

To control program source libraries, consider:

• (a) managing access to source code and libraries by established procedures
• (b) granting read and write access by business need, managed to address the risk of alteration or misuse
• (c) updating code and granting access through change control (8.32), only after authorisation
• (d) no direct access to the repository for developers: work goes through developer tools that control activities and authorisations
• (e) holding program listings in a secure environment with managed read and write access
• (f) keeping an audit log of all accesses and all changes to source code

If source code is to be published, consider extra integrity assurance such as digital signatures.

Related topics live elsewhere: separation of environments (A.8.31), secure coding (A.8.28), secure development life cycle (A.8.25) and change management (A.8.32).

Why Access to Source Code Matters

The Crown Jewels of Technology Companies

For technology companies, source code is the crown jewel. It represents years of investment, competitive advantage, and business logic. For all organizations, source code contains the security controls, authentication mechanisms, and data handling logic that protect the organization's information.

Key Statistics

• Software supply chain attacks grew sharply: Sonatype's 2022 State of the Software Supply Chain report recorded a 742% average annual increase over the previous three years
• Secrets in code remain common: GitGuardian's annual State of Secrets Sprawl reports find millions of new hard-coded secrets in public commits each year
• SolarWinds (2020) shows why build integrity matters: attackers compromised the build environment and injected code at build time (the SUNSPOT implant), so the signed release itself carried the backdoor. Signed commits, protected build systems and provenance (for example SLSA) address this

How It Goes Wrong (hypothetical patterns)

• A developer's GitHub account was compromised; the attacker accessed the entire source code repository, found hardcoded AWS credentials, and used them to access the company's cloud infrastructure, stealing customer data
• A contractor copied the entire source code of a fintech application before leaving; the contractor started a competing business with identical functionality, leading to a lawsuit
• An intern had write access to the main branch of a production application; they accidentally pushed experimental code to production, causing a 4-hour outage and data corruption
• A disgruntled employee inserted a backdoor into the source code before resigning; the backdoor was discovered 6 months later during a security audit, requiring a complete codebase review and remediation
• A company's source code was published on a public GitHub repository by a developer who forked it for "personal reference"; the code contained hardcoded database passwords and API keys, leading to immediate exploitation

Regulatory and Business Drivers

• DPDP Act 2023 requires protection of systems that process personal data; source code controls those systems
• SEBI CSCRF (2024) includes secure software development and change control for regulated entities' systems
• RBI Cyber Security Framework expects secure development, code review and access control for critical applications, and source-code escrow or availability arrangements for vendor-supplied critical applications
• PCI DSS v4.0.1 6.2.1–6.2.4 require secure development of bespoke software and code review before release
• SOC 2 CC8.1 covers authorised, tested and approved changes

Scope and Applicability

What Is Covered

• All proprietary source code (applications, services, APIs, microservices, scripts)
• All configuration files and infrastructure-as-code (IaC) templates
• All database schemas, migration scripts, and stored procedures
• All build scripts, deployment scripts, and CI/CD pipelines
• All version control repositories (Git, SVN, Mercurial, etc.)
• All development tools and environments (IDEs, compilers, debuggers)
• All software libraries, frameworks, and dependencies (open-source and commercial)
• All code documentation and architecture diagrams stored with code

What Is Not Covered

• End-user documentation (unless stored in code repository with sensitive information)
• Non-code intellectual property (designs, patents, trade secrets), though these may be in related repositories

Applicability by Organization Type

Key Definitions and Terminology

Relationship to Other Controls

Implementation Roadmap (Week-by-Week)

Week 1: Source Code Inventory and Risk Assessment

• Inventory all source code repositories and their locations
• Identify who has access to each repository and at what level (read, write, admin)
• Identify hardcoded secrets in repositories using scanning tools
• Assess current version control practices and access controls
• Identify third-party and open-source components in use
• Document current state and security gaps

Week 2: Policy and Access Framework Development

• Draft source code access policy
• Define repository access levels (read, write, admin, merge)
• Define branch protection rules (who can merge to main/production)
• Define code review requirements (number of reviewers, mandatory reviewers)
• Define CI/CD pipeline security requirements
• Define secret management policy (no hardcoded secrets, use vaults)
• Create source code classification and handling guidelines

Week 3: Repository Security Configuration

• Implement MFA for all repository access
• Configure branch protection rules on main/production branches
• Require pull requests and code reviews for all changes to main branches
• Remove direct push access to main/production branches
• Configure repository access controls (limit who has write/admin access)
• Enable audit logging for all repository activities
• Configure repository backup and recovery procedures

Week 4: Secret Detection and Remediation

• Scan all repositories for hardcoded secrets (API keys, passwords, tokens)
• Document all found secrets and their remediation status
• Rotate all exposed secrets immediately
• Implement secret scanning in CI/CD pipelines (pre-commit hooks, PR checks)
• Deploy secret management vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
• Train developers on secure secret management practices
• Establish process for handling secret leaks if they occur

Week 5: Code Review and Approval Workflow

• Implement mandatory code review workflow for all repositories
• Define minimum number of reviewers (typically 1–2 for standard, 2+ for critical)
• Define mandatory reviewers for sensitive areas (security team for auth code, DBA for schema changes)
• Implement status checks (automated tests, SAST, SCA) before merge
• Configure merge requirements (all checks must pass, all reviewers must approve)
• Create code review guidelines and security checklists
• Train developers on effective code review practices

Week 6: CI/CD Pipeline Security

• Secure CI/CD pipeline configurations (limit who can modify pipelines)
• Implement SAST (SonarQube, Checkmarx, Snyk Code) in pipelines
• Implement SCA (Snyk, Black Duck, Mend) in pipelines
• Implement container scanning if applicable
• Secure build agents and runners (limit access, harden configuration)
• Implement code signing for build artifacts
• Secure deployment credentials and keys (use vaults, no hardcoded credentials)

Week 7: Third-Party and Open-Source Management

• Inventory all third-party and open-source dependencies
• Implement dependency scanning in CI/CD pipelines
• Create approved dependency list and approval process for new dependencies
• Implement license compliance checking
• Establish vulnerability management process for dependencies (patching, upgrading)
• Create internal repository for approved dependencies (proxy/cache)
• Document dependency usage and risk acceptance

Week 8: Training, Documentation, and Audit

• Train all developers on secure coding practices and source code protection
• Train code reviewers on security-focused code review
• Create source code security guidelines and checklists
• Document all repository access controls and branch protection rules
• Conduct internal audit of source code access controls
• Verify all hardcoded secrets have been removed or rotated
• Prepare for external audit
• Plan for continuous improvement

Detailed Implementation Guidance

Figure · Tiers

Maturity levels for access to source code

Repository Access Control Model

Access Levels:

Repository Access Matrix:

Branch Protection Rules:

Code Review Requirements

Mandatory Code Review Elements:

Security Code Review Checklist:

• Input validation: All inputs are validated and sanitized
• Authentication: All endpoints require proper authentication
• Authorization: Access control checks are implemented correctly
• Session management: Sessions are handled securely
• Cryptography: Proper use of encryption, hashing, and randomness
• Error handling: Errors do not leak sensitive information
• Logging: Security events are logged appropriately
• Data protection: PII and sensitive data are handled per policy
• Injection prevention: SQL, NoSQL, OS command, LDAP, XML injection prevention
• XSS prevention: Output encoding and CSP headers
• CSRF protection: Anti-CSRF tokens implemented
• File upload: File uploads are validated and restricted
• API security: Rate limiting, authentication, input validation
• Secrets management: No hardcoded secrets; vault usage
• Dependency security: No known vulnerable dependencies

Secret Management

Secret Management Requirements:

Secret Scanning Implementation:

CI/CD Pipeline Security

Pipeline Security Requirements:

Pipeline Access Control:

• Limit who can modify pipeline configurations (admin only)
• Require approval for changes to production deployment pipelines
• Use separate pipelines for different environments (dev, staging, prod)
• Restrict pipeline execution permissions (only authorized users can trigger production deployments)
• Log all pipeline modifications and executions

Third-Party and Open-Source Management

Dependency Management Process:

1. Inventory: Maintain a complete inventory of all dependencies (direct and transitive)
2. Approval: New dependencies require approval from security and architecture teams
3. Scanning: Scan all dependencies for known vulnerabilities (CVEs) before use
4. License compliance: Verify licenses are compatible with organizational policy
5. Version pinning: Pin dependency versions to prevent unexpected updates
6. Monitoring: Continuously monitor for new vulnerabilities in existing dependencies
7. Patching: Establish SLA for patching vulnerable dependencies (critical: 7 days, high: 30 days)
8. Internal repository: Use internal proxy/cache for approved dependencies

Dependency Risk Levels:

Tools, Technologies, and Solutions

Version Control Platforms

Secret Management Solutions

SAST and Code Quality Tools

SCA and Dependency Management

Secret Scanning Tools

Policy and Procedure Templates

Source Code Access Policy Template

Code Review Checklist Template

Risk Assessment and Treatment

Risk Assessment Matrix for Source Code Access

Audit and Compliance Checklist

Internal Audit Checklist (30 Questions)

Policy and Governance (5 Questions)

1. Is a source code access policy documented and approved?
2. Are repository access levels defined and documented?
3. Are branch protection rules documented and enforced?
4. Are code review requirements documented?
5. Is the policy reviewed annually?

Repository Access (5 Questions)

6. Is all source code stored in version-controlled repositories?
7. Is MFA required for all repository access?
8. Is repository access based on role and need-to-know?
9. Are repository access logs maintained and reviewed?
10. Is repository access reviewed quarterly?

Branch Protection (5 Questions)

11. Are main/production branches protected from direct push?
12. Are pull requests required for all changes to protected branches?
13. Are status checks (tests, SAST, SCA) required before merge?
14. Are reviewers required to approve before merge?
15. Is force push disabled on protected branches?

Secret Management (5 Questions)

16. Is secret scanning implemented in all repositories?
17. Are pre-commit hooks installed to prevent secret commits?
18. Are there any hardcoded secrets in current repositories? (scan result)
19. Is a secret management vault deployed and used?
20. Are all exposed secrets rotated and removed from history?

CI/CD Security (5 Questions)

21. Is SAST implemented in CI/CD pipelines?
22. Is SCA implemented in CI/CD pipelines?
23. Are pipeline configurations stored in version control with PR approval?
24. Are build agents hardened and access-controlled?
25. Are production deployments require approval?

Third-Party Code (5 Questions)

26. Is there an inventory of all third-party dependencies?
27. Are dependencies scanned for vulnerabilities in CI/CD?
28. Is there an approval process for new dependencies?
29. Are vulnerable dependencies patched within SLA?
30. Is license compliance verified for all dependencies?

Audit Scoring

• 30–27: Excellent (Green), Full compliance
• 26–22: Good (Yellow), Minor gaps, address within 30 days
• 21–15: Needs Improvement (Orange), Significant gaps, address within 60 days
• 14–0: Critical (Red), Major non-compliance, immediate action required

Metrics and KPIs

Key Performance Indicators

Common Pitfalls and How to Avoid Them

Pitfall 1: "We're a Startup, We Don't Need This"

Problem: Startups and small teams skip source code controls because they prioritize speed over security. They use shared accounts, no code review, and no secret scanning. Solution: Implement lightweight controls from day one: (1) Use GitHub/GitLab with branch protection (free), (2) Require one reviewer for main branch (minimal overhead), (3) Install pre-commit hooks for secret scanning (free), (4) Use free SAST tools (SonarQube community, Semgrep). The cost of implementing these controls is negligible compared to the cost of a source code breach or secret leak. Security is not anti-velocity; it is pro-sustainability.

Pitfall 2: No Branch Protection on Main

Problem: Developers can directly push to main/master branch without review, tests, or approval. This leads to production bugs, security vulnerabilities, and failed deployments. Solution: Enable branch protection on all main, master, and release branches. Require pull requests. Require at least one reviewer. Require status checks to pass. Disable force push. This is a 5-minute configuration that prevents 90% of accidental production issues.

Pitfall 3: Hardcoded Secrets Everywhere

Problem: Developers embed API keys, passwords, and tokens directly in code "for convenience" or "for testing" and forget to remove them. These secrets end up in repositories, accessible to anyone with read access. Solution: (1) Deploy a secret management vault and train developers to use it, (2) Install pre-commit hooks that block secret commits, (3) Run secret scanning in CI/CD, (4) Establish a "secret leak response procedure" for when secrets are found, (5) Make secret scanning a mandatory status check for PRs. Make it easier to do the right thing (use vault) than the wrong thing (hardcode).

Pitfall 4: Code Review as a Rubber Stamp

Problem: Code review is required but treated as a formality. Reviewers approve without reading the code. Security issues are missed. The review process provides no value. Solution: (1) Make reviewers accountable, track review quality and comment depth, (2) Rotate reviewers to prevent "review fatigue," (3) Use automated tools (SAST, SCA) to catch issues before human review, (4) Train reviewers on what to look for, (5) Recognize good reviewers, (6) For critical code, require security team review. Code review is a security control, not a checkbox.

Pitfall 5: Ignoring Third-Party Dependencies

Problem: Organizations focus on their own code but ignore the open-source and third-party libraries they depend on. These libraries contain vulnerabilities that are actively exploited. Solution: (1) Maintain an inventory of all dependencies, (2) Scan dependencies in CI/CD with SCA tools, (3) Patch vulnerabilities within defined SLAs, (4) Vet new dependencies before approval, (5) Use dependency pinning to prevent unexpected updates, (6) Monitor for new vulnerabilities in existing dependencies. Your security is only as strong as your weakest dependency.

Pitfall 6: No CI/CD Pipeline Security

Problem: CI/CD pipelines are treated as "internal tools" with weak security. Build agents run with excessive privileges. Pipeline credentials are hardcoded. Anyone can modify pipeline configurations. Solution: (1) Store pipeline configurations in version control with PR approval, (2) Harden build agents (minimal OS, no unnecessary tools), (3) Use vault for all pipeline credentials, (4) Separate pipelines for dev/staging/prod, (5) Require approval for production deployments, (6) Log all pipeline activities. CI/CD pipelines are a critical part of your supply chain, they must be secured.

Pitfall 7: Source Code Access for Everyone

Problem: All developers have access to all repositories. A junior developer working on the website has access to the payment processing code. A contractor has access to proprietary algorithms. Solution: Implement repository-level access controls. Restrict access to payment code, security code, and proprietary algorithms to the teams that need it. Use GitHub/GitLab team-based access. Review access quarterly. Remove access when projects end. Just because someone is a "developer" does not mean they need access to all code.

Pitfall 8: No Source Code Backup or Recovery

Problem: Source code repositories are not backed up. A ransomware attack, accidental deletion, or malicious insider could destroy years of code. Solution: (1) Use hosted version control (GitHub, GitLab) with their built-in redundancy, (2) For self-hosted repositories, implement regular backups with off-site storage, (3) Test backup recovery annually, (4) Use immutable backups to prevent ransomware deletion, (5) Document recovery procedures. Source code is an irreplaceable asset, protect it like production data.

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian SaaS Company, Source Code Security Transformation (Growing company)

Organization: A 200-employee SaaS company in Bengaluru providing CRM and sales automation tools to SMBs in India and Southeast Asia Challenge: The company had grown rapidly from a 5-person startup to 200 employees. Development practices had not scaled with the team. There was no branch protection, all 40 developers could push directly to main. Code review was optional and rarely performed. Hardcoded AWS credentials were found in 12 repositories. A developer accidentally pushed a test script that exposed the entire customer database to a public API endpoint. The incident was discovered by a security researcher who reported it publicly. The company faced customer churn, reputational damage, and a DPDP Act investigation. Before State:

• 40 developers with direct push access to main branch
• No mandatory code review; optional PRs were rarely used
• No secret scanning; 12 repositories contained hardcoded AWS credentials
• No SAST or SCA in CI/CD
• No dependency approval process; 30+ dependencies with known vulnerabilities
• All developers had access to all 50 repositories
• No source code access policy
• CI/CD pipelines used hardcoded credentials
• No branch protection, no status checks, no merge requirements

Implementation: Week 1: Emergency lockdown. Enabled branch protection on all repositories. Removed direct push access. Rotated all exposed AWS credentials. Week 2: Implemented mandatory pull requests with 1 reviewer minimum for all repositories. Week 3: Deployed GitHub secret scanning and pre-commit hooks across all repositories. Week 4: Implemented SAST (SonarQube) and SCA (Snyk) in CI/CD pipelines. Week 5: Deployed AWS Secrets Manager for all application secrets. Removed all hardcoded credentials. Week 6: Implemented dependency approval process. Patched 30+ vulnerabilities. Week 7: Restricted repository access to project teams only. Removed cross-team access. Week 8: Trained all developers on secure coding, code review, and secret management. Month 3: Conducted internal audit. All repositories compliant.

Results (After 6 Months):

• 100% of repositories protected with branch protection and PR requirements
• 100% of repositories with secret scanning enabled
• 0 hardcoded secrets in all repositories (verified via scan)
• 100% of PRs with code review compliance (up from 15%)
• 100% of CI/CD pipelines with SAST and SCA
• 30+ vulnerabilities patched; dependency management process established
• Repository access restricted to project teams; 40+ unnecessary access rights removed
• Customer trust restored; DPDP Act investigation resolved with no penalty
• New enterprise clients signed citing improved security posture
• Zero source code security incidents since implementation

Investment: (GitHub Enterprise, SonarQube, Snyk, AWS Secrets Manager, training, audit)

Key Lesson: Source code security is not "enterprise overhead", it is foundational for any company that builds software. The "move fast and break things" mentality must evolve to "move fast and secure things" as the company grows.

Illustrative Scenario 2: Large Indian IT Services Company, Client Source Code Protection

Organization: A 5,000-employee IT services company with 200+ clients across banking, healthcare, retail, and government sectors. The company manages source code for both proprietary products and client projects. Before State:

• 200+ client projects with inconsistent source code security
• Client code often mixed with other projects in shared repositories
• No standardized branch protection across client projects
• No secret scanning for client code
• No SAST/SCA for client code unless specifically requested
• No repository access review process
• 15 developers had access to the US bank's payment code when only 5 were on the project
• No source code access policy specific to client projects
• CI/CD pipelines for client projects used shared credentials

Implementation: Phase 1 (Months 1–2): Developed global source code access policy with client-specific addendums. Defined "client code isolation" requirements. Phase 2 (Months 3–4): Implemented repository isolation, each client project got a dedicated repository or namespace with strict access controls. Phase 3 (Months 5–6): Deployed standardized branch protection, mandatory PRs, and secret scanning across all client repositories. Phase 4 (Months 7–8): Implemented SAST and SCA for all client projects. Patched identified vulnerabilities. Phase 5 (Months 9–10): Implemented quarterly access reviews for all client repositories. Removed 300+ excessive access rights. Phase 6 (Months 11–12): Deployed dedicated CI/CD pipelines per client with isolated credentials and hardened build agents. Phase 7 (Month 13): Client re-audit. All findings cleared. Contract retained.

Results (After 18 Months):

• 100% of client repositories isolated with dedicated access controls
• 100% of client repositories with branch protection and mandatory PRs
• 100% of client repositories with secret scanning
• 100% of client repositories with SAST and SCA
• 300+ excessive access rights removed across all client projects
• 100% of client CI/CD pipelines with dedicated credentials and hardened agents
• 5 new clients signed citing the company's source code security practices
• SOC 2 Type II certification achieved (source code controls were a key factor)
• CMMI Level 5 appraisal maintained with no source code security issues

Key Lesson: For IT services companies, client source code protection is a business-critical capability. Client audits are increasingly rigorous, and source code security failures can result in contract termination, regulatory action, and reputational damage. Standardized, client-isolated source code security is a competitive advantage.

Multi-Framework Mapping

ISO 27001:2022 A.8.4 to Other Frameworks

Regulatory and Industry Context

India-Specific Regulatory Requirements

Digital Personal Data Protection Act 2023: code that processes personal data is part of the systems the fiduciary must protect (s.8(5)); hard-coded credentials or personal data in repositories are a breach risk; failing to take safeguards can attract a penalty of up to ₹250 crore.

RBI: the Cyber Security Framework (2016) and the Master Direction on IT Governance (2023) expect secure development, change control and, for vendor-supplied critical applications, source-code escrow or availability arrangements.

SEBI CSCRF (2024): secure development, change control and testing for regulated entities' systems, scaled by entity category.

Information Technology Act 2000: s.43 and s.66 (unauthorised access and computer-related offences); s.65 (tampering with computer source documents required to be kept by law); s.72A (disclosure in breach of a lawful contract). Code written for an employer usually belongs to it under the Copyright Act 1957 (s.17); contractors need an assignment clause.

Industry-Specific Context

• IT/ITeS: client contracts usually require segregated repositories per client, access approval by the client, and return or deletion of code at contract end.
• BFSI: code review and change control for core and payment systems; escrow for vendor-supplied critical applications.
• Healthcare and medical devices: software in medical devices follows the Medical Device Rules 2017 and the maker's quality system where they apply.
• SaaS: protect the CI/CD pipeline as carefully as the repository; multi-tenant isolation code deserves extra review.

Roles and Responsibilities (RACI)

Documentation and Evidence Requirements

Continuous Improvement

Maturity Model for A.8.4

Continuous Improvement Activities

Monthly:

• Secret scanning results review
• SAST/SCA findings remediation tracking
• Dependency vulnerability monitoring
• Code review compliance metrics
• Repository access log review

Quarterly:

• Repository access reviews
• Dependency inventory update and approval
• Code review effectiveness assessment
• SAST/SCA tool effectiveness review
• Developer security training refresh
• Internal audit of source code controls

Annually:

• Full policy review
• Complete source code security risk assessment
• Technology and tool evaluation (new SAST/SCA tools, improved secret scanning)
• Benchmark against industry best practices
• External audit preparation
• Maturity assessment against target level

Trigger-Based:

• After any source code security incident (secret leak, backdoor, code theft)
• Upon new repository creation or acquisition
• Upon new tool or technology adoption
• After significant audit findings
• Upon client audit or security assessment feedback
• Upon regulatory change

FAQ

Q1: Does A.8.4 apply to all types of code, including scripts and configuration files? A: Yes. A.8.4 applies to all source code, including application code, scripts, configuration files, infrastructure-as-code (Terraform, CloudFormation, Ansible), database schemas, and build/deployment pipelines. All of these contain logic, credentials, or configurations that could be exploited if accessed improperly. Treat infrastructure-as-code with the same rigor as application code.

Q2: Do we need to restrict access to open-source code we use? A: Open-source code itself is publicly available, but your organization's usage, modifications, and integration of open-source code should be managed. Restrict access to your internal forks, modifications, and dependency configurations. Use an internal dependency proxy to cache approved versions. Document which open-source components you use for security and license compliance. The open-source code is public, but your specific usage patterns and modifications may reveal information about your systems.

Q3: How do we handle code review for urgent hotfixes? A: Urgent hotfixes need a balance of speed and security. Implement an expedited review process: (1) Minimum 1 reviewer (instead of 2), (2) Security team notification (rather than approval), (3) Post-merge review within 24 hours, (4) All standard checks must still pass (tests, secret scanning), (5) Document the emergency and why standard review was bypassed, (6) Conduct a post-incident review. Do not allow "urgent" to become a routine excuse for bypassing review. If everything is urgent, nothing is.

Q4: What is the best way to manage secrets in containerized environments? A: For containers: (1) Never bake secrets into container images, (2) Use orchestration secrets (Kubernetes Secrets, Docker Swarm secrets) or external vaults (Vault, AWS Secrets Manager), (3) Inject secrets at runtime via environment variables or mounted files, (4) Use short-lived, dynamic credentials where possible, (5) Rotate secrets regularly, (6) Scan container images for secrets before deployment, (7) Use secret-scanning tools in CI/CD. Container images are often stored in registries with broad access, secrets in images are easily exposed.

Q5: How do we protect source code when using offshore or outsourced development? A: Offshore development requires enhanced source code protection: (1) NDA and security agreement with offshore vendor, (2) Limited repository access (only the specific project), (3) Separate repository or branch for offshore work, (4) Enhanced code review for offshore contributions, (5) DLP monitoring for code exfiltration, (6) No access to security-critical code (auth, encryption, payment) unless absolutely necessary, (7) Regular access reviews, (8) Immediate revocation upon contract end, (9) Code watermarking or fingerprinting for attribution if needed, (10) Legal framework for IP protection in the offshore jurisdiction.

Q6: Should we encrypt source code at rest in repositories? A: Most version control platforms (GitHub, GitLab, Bitbucket) encrypt data at rest as part of their platform security. For self-hosted repositories, ensure the underlying storage is encrypted. However, source code is generally not encrypted at the repository level because it needs to be readable for development. The protection comes from access controls, not encryption. If you have extremely sensitive code (e.g., cryptographic algorithms, proprietary trading strategies), consider additional controls: compartmentalized access, code obfuscation, or specialized secure development environments.

Q7: What is the difference between SAST and SCA? A: SAST (Static Application Security Testing) analyzes your own source code for security vulnerabilities (SQL injection, XSS, buffer overflows, etc.). SCA (Software Composition Analysis) analyzes your third-party and open-source dependencies for known vulnerabilities (CVEs) and license issues. Both are essential: SAST finds vulnerabilities in your code; SCA finds vulnerabilities in code you depend on. Implement both in your CI/CD pipeline.

Q8: How do we handle legacy code with no version control? A: Legacy code without version control is a significant risk. Steps: (1) Import legacy code into a version control system immediately, (2) Establish branch protection and access controls on the new repository, (3) Implement gradual code review for any changes, (4) Run SAST and secret scanning on the imported code, (5) Document the code's purpose and ownership, (6) Plan for modernization or replacement, (7) If the code is critical, consider a security review of the entire codebase. Do not let legacy code remain outside version control, it is unmanageable and unprotectable.

Q9: What is the most common audit finding for A.8.4? A: The most common findings are: (1) No branch protection on main/production branches, (2) No mandatory code review, (3) Hardcoded secrets in repositories, (4) No secret scanning, (5) No SAST or SCA in CI/CD, (6) Broad repository access (all developers access all repos), (7) No access review for repositories, (8) Weak CI/CD pipeline security. Auditors will check repository settings, scan for secrets, review CI/CD configurations, and verify access controls.

Q10: How do we balance code security with developer productivity? A: Security should enhance, not hinder, productivity. Strategies: (1) Automate security checks (SAST, SCA, secret scanning) so they run without manual intervention, (2) Use fast tools that provide feedback within minutes, (3) Integrate security tools into the IDE for immediate feedback, (4) Provide clear security guidelines so developers know expectations, (5) Train developers on secure coding to reduce rework, (6) Use pre-approved libraries and patterns to reduce decision fatigue, (7) Measure and optimize security tool performance to minimize pipeline delays. Security that slows development will be circumvented. Security that is invisible and fast will be embraced.

Q11: Do we need to scan all code for secrets, including test code and documentation? A: Yes, scan everything. Test code often contains real credentials for test environments that are similar to production credentials. Documentation may contain example code with placeholder credentials that developers copy and modify. Configuration files may contain real secrets. Scan the entire repository including branches, pull requests, and history. Use "push protection" to prevent secrets from being pushed in the first place.

Q12: How do we manage source code access for acquisitions? A: When acquiring a company, assess their source code security practices immediately: (1) Audit their repositories for access controls, secrets, and vulnerabilities, (2) Implement emergency controls if gaps are found, (3) Integrate their repositories into your version control system, (4) Apply your branch protection and access control standards, (5) Run SAST and secret scanning on their entire codebase, (6) Train their developers on your security practices, (7) Conduct a complete security review of their code before integration. Do not assume acquired code meets your security standards.

Q13: What is the cost of implementing A.8.4 for a growing company? A: For a company with about 30 developers, the main costs are a source code platform tier that includes branch protection, audit logs and secret scanning (often part of the plan you already pay for), SAST and dependency scanning (open-source options exist), and reviewer time. Pipeline hardening is mostly configuration work.

Q14: How do we handle source code for mobile applications? A: Mobile apps have unique source code security challenges: (1) Code can be reverse-engineered from APK/IPA files, so obfuscation (ProGuard, R8) is recommended, (2) API keys in mobile code are easily extracted, use API key rotation, certificate pinning, and server-side validation, (3) Use mobile-specific SAST tools, (4) Implement runtime application self-protection (RASP) if needed, (5) Secure the CI/CD pipeline for mobile builds, (6) Code signing must be protected (signing keys stored in HSM or vault), (7) Beta/test builds must not contain production credentials or endpoints.

Q15: What is supply chain security and how does it relate to source code? A: Supply chain security protects the end-to-end process of software development and delivery from code to deployment. It includes: (1) Source code security (this control), (2) Dependency security (SCA), (3) Build pipeline security (CI/CD protection), (4) Artifact security (code signing, checksums), (5) Deployment security (environment protection, deployment approval). Supply chain attacks (like SolarWinds) exploit weaknesses in this chain. A.8.4 is a critical component of supply chain security, but it must be complemented by controls for dependencies, builds, and deployments. Modern organizations should implement a complete software supply chain security program.

Q16: How do we protect source code for AI/ML models? A: AI/ML source code contains unique intellectual property: model architectures, training pipelines, hyperparameters, and feature engineering logic. Protect AI source code with: (1) Restricted access to model training code (only ML engineers, not all developers), (2) Separate repositories for model code vs. application code, (3) Protect training data access (separate from source code), (4) Secure model artifact storage (registry with access controls), (5) Protect inference code and deployment scripts, (6) Implement model versioning with integrity checks, (7) Protect experiment tracking data (contains hyperparameters and results), (8) Code review for all model changes, (9) Secure MLOps pipeline (CI/CD for ML), (10) Model documentation and card security.

Q17: What is the role of source code access in compliance audits? A: Auditors verify source code access controls to ensure: (1) Only authorized developers can access code, (2) Changes are reviewed and approved before merging, (3) No unauthorized modifications have occurred, (4) Secrets are not present in code, (5) Build and deployment processes are secure, (6) Source code is backed up and recoverable, (7) Access reviews are conducted regularly. Provide auditors with repository access logs, branch protection settings, code review records, and secret scanning reports.

References and Further Reading

Standards and Frameworks

• ISO/IEC 27001:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements
• ISO/IEC 27002:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Controls
• NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-218, Secure Software Development Framework (SSDF)
• PCI DSS v4.0.1, Payment Card Industry Data Security Standard
• CIS Controls v8, CIS Controls Version 8
• OWASP Software Assurance Maturity Model (SAMM)

Indian Regulations

• Digital Personal Data Protection Act, 2023 (India)
• Information Technology Act, 2000 (as amended)
• RBI Cyber Security Framework for Banks
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024

Books and Publications

• ISO 27001/27002: A Pocket Guide by Alan Calder
• NIST 800-218: Secure Software Development Framework (NIST)
• The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis
• OWASP SAMM (Software Assurance Maturity Model)
• Secure Coding in C and C++ by Robert C. Seacord

Source Code Security Best Practices Summary

Source Code Security Rules of Thumb

1. Thou shalt not share repository credentials: Use SSH keys, personal access tokens, or SSO, never shared passwords
2. Thou shalt enforce branch protection: No direct pushes to main/master, all changes via pull request
3. Thou shalt require code review: Minimum one reviewer, no self-approval for critical code
4. Thou shalt scan for secrets: Pre-commit hooks, push protection, regular repository scans
5. Thou shalt not commit secrets: Use vaults, environment variables, and secret injection
6. Thou shalt implement least privilege for writing: read access can be broad inside the organisation; write and merge rights go to designated owners; admins get configuration access
7. Thou shalt audit all access: Log all repository access, review logs quarterly, alert on anomalies
8. Thou shalt protect build pipelines: Signed commits, verified builds, immutable artifacts
9. Thou shalt secure code signing: Keys in HSM, dual control, never in source code or CI/CD variables
10. Thou shalt review write and admin access quarterly: Remove stale access, validate business need, document exceptions
11. Thou shalt sign what you publish: Sign releases and published code so users can verify integrity

This guide is part of the Singahi ISO 27001:2022 Annex A Control Guide Series.