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 Standard Actually Requires

Figure · Process

What A.8.4 asks you to do

ISO 27001:2022 Annex A.8.4 states:

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.

ISO 27002:2022 expands this into practical guidance covering:

1. Access restriction, Source code should only be accessible to authorized developers and personnel with a legitimate need
2. Version control, All source code must be managed through version control systems with access logging
3. Repository protection, Source code repositories must be secured with appropriate authentication and authorization
4. Code integrity, Changes to source code must be tracked, reviewed, and approved before being committed
5. Segregation of environments, Development, testing, and production environments must be separated
6. Build and deployment controls, Build pipelines must be secured and access-controlled
7. Third-party code, Open-source and third-party libraries must be managed and vetted

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

• Malicious code injection (supply chain attacks) increased by 742% in recent years
• Hardcoded secrets (API keys, passwords, tokens) in source code are found in 80% of code repositories
• Unauthorized source code access was the entry point for several major breaches, including the SolarWinds attack

Real-World Consequences

• 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 Cybersecurity Circular requires trading and financial systems to have secure development and access controls
• RBI Cyber Security Framework mandates source code review and access controls for critical banking applications
• PCI DSS v4.0 Requirement 6 requires secure software development and access controls for cardholder data environments
• SOC 2 CC7.1 requires system operations to be monitored, including changes to source code

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

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 impact of implementing these controls is negligible compared to the impact 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) ROI: Prevented customer churn worth ARR. The exposed database incident could have overhead in fines, notification, and remediation. The investment in source code security was essential for the company's enterprise readiness and long-term viability.

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

Investment: (repository isolation, security tools, CI/CD hardening, access reviews, training, audit)

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

NIST 800-53 Rev 5:

• CM-3: Configuration Change Control, Maps to source code change control and branch protection
• SA-10: Developer Configuration Management, Maps to source code management and version control
• SA-11: Developer Testing and Evaluation, Maps to code review and security testing
• SA-15: Development Process Standards, Maps to secure development practices
• SC-28: Protection of Data at Rest, Maps to secret management in code

PCI DSS v4.0:

• Requirement 6.2: Security in software development processes
• Requirement 6.3: Security testing and vulnerability management
• Requirement 6.4: Security in software development lifecycle
• Requirement 6.5: Address common vulnerabilities in software

SOC 2 CC7.1:

• System operations monitoring, including changes to source code and systems

CIS Controls v8:

• CIS Control 8: Audit Log Management, Source code access logging
• CIS Control 7: Continuous Vulnerability Management, Dependency vulnerability management
• CIS Control 3: Data Protection, Secret management in code

Regulatory and Industry Context

India-Specific Regulatory Requirements

Digital Personal Data Protection (DPDP) Act 2023:

• Source code handling personal data must be protected with appropriate access controls
• Hardcoded personal data or credentials in source code violate data protection principles
• Security vulnerabilities in code that expose personal data can result in penalties up to

RBI Cyber Security Framework:

• Critical banking application source code must have access controls and code review
• Changes to core banking code require approval and audit trail
• Source code for payment systems must be protected with enhanced controls
• Annual cyber audit must include source code security review

SEBI Cybersecurity Circular:

• Trading system source code must be protected with access restriction and version control
• Code changes to trading systems must be tested and approved before deployment
• Source code access must be logged and audited

Information Technology Act 2000 (as amended):

• Section 43: Penalty for unauthorized access to computer systems (including source code repositories)
• Section 66: Computer-related offenses involving source code theft or tampering

Industry-Specific Context

IT/Software Services:

• Client source code protection is a contractual requirement for most enterprise clients
• Source code security is often audited during client security assessments
• ISO 27001, SOC 2, and CMMI all require source code access controls
• Offshore development centers must demonstrate secure source code practices
• Source code theft is a major IP risk for IT services companies

BFSI:

• RBI mandates code review and access controls for critical banking applications
• Payment system code must meet PCI DSS secure development requirements
• Trading algorithm code is highly sensitive and requires strict access restriction
• Code changes to financial systems must be audited and approved

Healthcare:

• Patient data handling code must be reviewed for security and compliance (DPDP/HIPAA equivalent)
• Medical device software requires FDA/regulatory code review
• NABH accreditation requires secure development practices
• Code handling ePHI must have access controls and audit trails

Government/Defense:

• Classified application code requires compartmentalized access (need-to-know)
• Security-cleared personnel required for sensitive code access
• Code changes to citizen-facing systems must be rigorously reviewed
• Ministry of Home Affairs guidelines for secure software development

SaaS/Cloud:

• Multi-tenant isolation code is critical for customer data protection
• API security code must be protected and reviewed
• CI/CD pipeline security is essential for secure deployments
• Zero Trust architecture increasingly requires secure source code practices
• Customer audit rights often include source code security assessment

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 impact of implementing A.8.4 for a growing company? A: For a company with 50 repositories and 30 developers: GitHub/GitLab with security features (–/year), SAST (SonarQube or Snyk, –/year), SCA (Snyk or Mend, –/year), secret scanning (often included in platform or free tools, –/year), secret management vault (HashiCorp Vault or cloud-native, –/year), training (–). Total: –/year. Many tools are free or lightweight for small teams. The investment is modest compared to the impact of a secret leak or code breach.

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, 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 Circular CIR/ISD/2019 on Cyber Security and Cyber Resilience

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

The 10 Commandments of Source Code Security

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, Developers get read access, approvers get merge access, admins get config 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 access quarterly, Remove stale access, validate business need, document exceptions

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