Skip to content

Secure Software Development Lifecycle (SDLC) Policy

Document Information
Version {{version}}
Effective Date {{effective_date}}
Document Owner {{document_owner}}
Next Review {{next_review_date}}
Approved By {{approved_by}}

Purpose

The purpose of this policy is to establish comprehensive security governance for all software development activities at {{company_name}}, hereafter referred to as "the company". This policy ensures that security is integrated throughout the software development lifecycle (SDLC) for all custom applications, including web applications, mobile applications, traditional applications, and artificial intelligence applications.

This policy implements the Australian Cyber Security Centre (ACSC) Information Security Manual (ISM) Guidelines for Software Development to protect the confidentiality, integrity, and availability of software systems and data.

Scope

This policy applies to:

  • All software development activities conducted by or on behalf of the company
  • All custom applications developed for internal use or external customers
  • All employees, contractors, third-party developers, and service providers involved in software development
  • All development, testing, staging, and production environments

This policy applies to the following types of software development:

  • Web applications and web APIs
  • Mobile applications (iOS, Android)
  • Traditional applications (desktop, server applications)
  • Artificial intelligence and machine learning applications
  • Cloud-native and microservices applications

Roles and Responsibilities

Role Responsibility
{{development_authority}} Overall accountability for secure software development practices
{{security_officer}} Oversight of application security controls and testing
Development Team Leads Implementing secure development practices within teams
Software Developers Following secure coding practices and security requirements
{{it_provider}} Managing development environments and build infrastructure
{{security_provider}} Conducting security testing and vulnerability assessments

1. Development Environment Management

1.1 Environment Segregation

ACSC ISM Control: ISM-0400, ISM-1419, ISM-1420

The company maintains segregated environments to minimize the likelihood of faulty or malicious code being introduced into production:

  • Development Environment: For active software development and coding
  • Testing Environment: For functional and security testing
  • Staging Environment: For pre-production validation and final testing
  • Production Environment: For live operational systems

Requirements:

  1. Development, testing, staging and production environments are segregated (ISM-0400)
  2. Development and modification of software only takes place in development environments (ISM-1419)
  3. Data from production environments is not used in non-production environments unless the non-production environment is secured to at least the same level as the production environment (ISM-1420)
  4. Access to each environment is restricted based on role and job function
  5. Network segmentation separates environments to prevent unauthorized access
  6. Environment promotion follows defined change control procedures

1.2 Authoritative Source for Software

ACSC ISM Control: ISM-2023, ISM-2024, ISM-1422, ISM-1816

The company maintains an authoritative source for all software development activities:

  1. An authoritative source for software is established and maintained (ISM-2023)
  2. The authoritative source for software is used for all software development activities (ISM-2024)
  3. Unauthorised access to the authoritative source for software is prevented (ISM-1422)
  4. Unauthorised modification of the authoritative source for software is prevented (ISM-1816)

Implementation:

  • Version control system (e.g., Git) serves as the authoritative source
  • Access controls based on role-based permissions
  • Multi-factor authentication required for all access
  • Audit logging of all access and modifications
  • Branch protection rules for production code
  • Code review requirements before merging to protected branches

1.3 Issue Tracking

ACSC ISM Control: ISM-2025

An issue tracking solution is used to link software development tasks to security issues and decisions, change or feature requests, programming issues, or bug fixes (ISM-2025).

Requirements:

  • All code changes linked to documented requests or decisions
  • Security issues tracked with appropriate priority levels
  • Traceability from requirements through implementation to deployment
  • Integration between version control and issue tracking systems

2. Software Artefacts and Build Security

2.1 Software Artefact Security

ACSC ISM Control: ISM-2026, ISM-2027, ISM-2028, ISM-2029, ISM-2030

All software artefacts (compiled code, libraries, executables, configuration files) are secured:

  1. All software artefacts are scanned for malicious code before being imported into the authoritative source for software, including all compiled code, third-party libraries and software components (ISM-2026)
  2. All software artefacts are verified by a digital signature, or a secure hash provided over a secure channel, before being imported into the authoritative source for software (ISM-2027)
  3. All imported or referenced third-party software artefacts are tested using static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) before being imported into the authoritative source for software and periodically throughout the software development life cycle (ISM-2028)
  4. The authoritative source for software restricts the use and import of third-party libraries and software components to trustworthy sources (ISM-2029)
  5. Scanning is used during commits to identify plain text or encoded secrets and keys, which are then blocked from being stored in the authoritative source for software (ISM-2030)

2.2 Build Solution Security

ACSC ISM Control: ISM-2031, ISM-2032

The build process implements security controls:

  1. Compilers, interpreters and build tools (including pipelines) that provide security features to improve executable file security are implemented and such security features are used (ISM-2031)
  2. The build solution ensures that all automated testing is completed without warnings, alerts or errors before building software artefacts (ISM-2032)

Requirements:

  • Automated build pipelines with security gates
  • All compiler security features enabled (e.g., ASLR, DEP, stack protection)
  • Build failures on security test failures
  • Immutable build environments
  • Build provenance tracking

3. Secure Software Development Practices

3.1 Security Requirements and Design

ACSC ISM Control: ISM-2033, ISM-2034, ISM-2035, ISM-2036

Security is integrated from the earliest stages of development:

  1. All software security requirements are documented, stored securely and maintained throughout the software development life cycle (ISM-2033)
  2. Security design decisions are documented and reviewed throughout the software development cycle (ISM-2034)
  3. Security roles, responsibilities and knowledge requirements required to support the software development life cycle are identified and documented (ISM-2035)
  4. Security responsibilities for software developers are identified and documented (ISM-2036)

3.2 Developer Training and Competency

ACSC ISM Control: ISM-2037, ISM-2038

Developers maintain appropriate security knowledge:

  1. Software developers that lack sufficient cybersecurity knowledge and skills required for their projects or tasks undertake suitable training on secure software development and programming practices (ISM-2037)
  2. A software developer cybersecurity knowledge and skills register is implemented and maintained (ISM-2038)

Requirements:

  • Annual secure coding training for all developers
  • Training on OWASP Top 10 and common vulnerabilities
  • Language-specific secure programming training
  • Training records maintained and reviewed annually
  • Competency assessments for security-critical projects

3.3 Secure by Design Principles

ACSC ISM Control: ISM-0401, ISM-1238, ISM-2039, ISM-2040, ISM-2041, ISM-2042, ISM-1780

Secure by Design and Secure by Default principles are mandatory:

  1. Secure by Design principles and practices are followed throughout the software development life cycle (ISM-0401)
  2. Threat modelling is used in support of the software development life cycle (ISM-1238)
  3. The software threat model is reviewed throughout the software development life cycle to ensure it reflects the as-built software and any changes to the threat environment (ISM-2039)
  4. Secure programming practices for the chosen programming language are used for software development (ISM-2040)
  5. Memory-safe programming languages, or less preferably memory-safe programming practices, are used for software development (ISM-2041)
  6. Secure by Default principles and practices are followed throughout the software development life cycle, including by ensuring that all built-in security measures are included and enabled in the base product at no extra cost to consumers (ISM-2042)
  7. SecDevOps practices are used for software development (ISM-1780)

Secure Coding Practices:

  • Use memory-safe programming languages where possible (C#, Go, Java, Ruby, Rust, Swift)
  • If using memory-unsafe languages (C, C++), implement memory-safe practices
  • Follow language-specific secure coding guidelines (CERT, OWASP)
  • Implement least privilege principles in application design
  • Defense in depth with multiple security layers
  • Fail securely - errors do not expose sensitive information
  • Minimize attack surface area

3.4 Code Quality and Maintainability

ACSC ISM Control: ISM-2043

Software is architected and structured to support readability and maintainability (ISM-2043).

Requirements:

  • Code follows established style guides and conventions
  • Meaningful variable and function names
  • Comprehensive code comments for complex logic
  • Modular design with clear separation of concerns
  • Documentation of architectural decisions

3.5 Digital Signatures and Integrity

ACSC ISM Control: ISM-1796, ISM-1797, ISM-2050

Software integrity is protected through digital signatures:

  1. Files containing executable content are digitally signed by a certificate with a verifiable chain of trust as part of software development (ISM-1796)
  2. Installers, patches and updates are digitally signed or provided with cryptographic checksums as part of software development (ISM-1797)
  3. When digital signatures are processed by software, they are validated against a certificate trust chain and checked for revocation using a Certificate Revocation List or with the Online Certificate Status Protocol (ISM-2050)

3.6 Security Features and Configuration

ACSC ISM Control: ISM-2044, ISM-2045, ISM-2046, ISM-2047, ISM-2048, ISM-2049

Applications implement security features correctly:

  1. Software has no default credentials; however, if credentials are required, they are created on first install by the installing organisation (ISM-2044)
  2. Application backwards compatibility does not compromise any security measures or features (ISM-2045)
  3. Where software allows user impersonation, sensitive data is not logged and appropriate permissions are set (ISM-2046)
  4. Where software allows an authentication factor to be reset, the user is notified of the reset through a secondary channel (ISM-2047)
  5. When user permissions or credentials are changed, software forces all impacted users to re-authenticate (ISM-2049)

3.7 Application Logging

ACSC ISM Control: ISM-2051, ISM-2052, ISM-1911

Applications generate appropriate event logs:

  1. Software generates sufficient event logs to support the detection of cybersecurity events (ISM-2051)
  2. Event logs produced by software ensure that any sensitive data is protected (ISM-2052)
  3. Security-relevant software crashes and error messages are centrally logged (ISM-1911)

3.8 Security Documentation

ACSC ISM Control: ISM-1798, ISM-2053

Security guidance is provided for application consumers:

  1. Secure configuration guidance, in the form of a hardening guide or loosening guide, is produced and made available to consumers as part of software development (ISM-1798)
  2. End of life procedures for software, covering how to remove the software and how to archive or destroy any user accounts and data, are produced and made available to consumers (ISM-2053)

4. Software Bill of Materials (SBOM)

ACSC ISM Control: ISM-2054, ISM-1730, ISM-2055, ISM-2056

Software transparency through SBOM management:

  1. If a software bill of materials is available for imported third-party software components, it is used during software development to ensure such software components have no known vulnerabilities (ISM-2054)
  2. A software bill of materials is produced and made available to consumers of software (ISM-1730)
  3. If a software build provenance is available for imported third-party software components, it is used during software development to ensure such software components are built to an appropriate standard (ISM-2055)
  4. A software build provenance is produced and made available to consumers of software (ISM-2056)

Requirements:

  • SBOM generated for all releases
  • SBOM includes all open source and commercial components
  • SBOM format: SPDX or CycloneDX standard
  • Continuous monitoring of SBOM components for vulnerabilities
  • Regular updates of vulnerable dependencies
  • Documentation of dependency security review process

5. Application Programming Interface (API) Security

5.1 Network API Security

ACSC ISM Control: ISM-1818, ISM-2013, ISM-1817, ISM-2014, ISM-1910, ISM-2015

APIs implement strong authentication and logging:

  1. Authentication and authorisation of clients is performed when clients call network APIs that facilitate modification of data and are accessible over the internet (ISM-1818)
  2. Authentication and authorisation of clients is performed when clients call network APIs that facilitate modification of data but are not accessible over the internet (ISM-2013)
  3. Authentication and authorisation of clients is performed when clients call network APIs that facilitate access to data not authorised for release into the public domain and are accessible over the internet (ISM-1817)
  4. Authentication and authorisation of clients is performed when clients call network APIs that facilitate access to data not authorised for release into the public domain but are not accessible over the internet (ISM-2014)
  5. Network API calls that facilitate modification of data, or access to data not authorised for release into the public domain, and are accessible over the internet, are centrally logged (ISM-1910)
  6. Network API calls that facilitate modification of data, or access to data not authorised for release into the public domain, but are not accessible over the internet, are centrally logged (ISM-2015)

Implementation:

  • OAuth 2.0 or equivalent for API authentication
  • API keys with proper rotation policies
  • Rate limiting and throttling
  • API versioning strategy
  • Comprehensive API documentation
  • API gateway for centralized control

6. Input Handling and Validation

6.1 Input Validation

ACSC ISM Control: ISM-1240, ISM-2016, ISM-2057, ISM-2058, ISM-2059

All input is validated and sanitized:

  1. Validation and sanitisation are performed on all input received over the internet by software (ISM-1240)
  2. Validation and sanitisation are performed on all input received over a local network by software (ISM-2016)
  3. All input validation rules are documented, matched in code and tested with both positive and negative unit testing or integration testing (ISM-2057)
  4. Data sources and serialised data inputs are validated before being deserialised (ISM-2058)
  5. File uploads or input are restricted to specific file types, with malicious content scanning occurring prior to file access, file execution or file storage (ISM-2059)

Validation Requirements:

  • Whitelist validation (allow known good) preferred over blacklist
  • Data type validation (string, integer, email, URL, etc.)
  • Length and format validation
  • Range validation for numeric inputs
  • Rejection of malicious patterns (SQL injection, XSS, command injection)
  • Validation occurs server-side (not client-side only)

6.2 Database Interaction Security

ACSC ISM Control: ISM-1275, ISM-1276, ISM-1278, ISM-1536

Database queries are secured against injection attacks:

  1. All queries to databases from software are filtered for legitimate content and correct syntax (ISM-1275)
  2. Parameterised queries or stored procedures, instead of dynamically generated queries, are used by software for database interactions (ISM-1276)
  3. Software is designed or configured to provide as little error information as possible about the structure of databases (ISM-1278)
  4. All queries to databases from software that are initiated by users, and any resulting crash or error messages, are centrally logged (ISM-1536)

Requirements:

  • Mandatory use of parameterized queries or prepared statements
  • Object-Relational Mapping (ORM) frameworks used correctly
  • Input validation before database operations
  • Least privilege database accounts for applications
  • Generic error messages to users (detailed errors logged only)

7. Security Testing

ACSC ISM Control: ISM-0402, ISM-2060, ISM-2061, ISM-2062

Comprehensive security testing throughout development:

  1. Software is comprehensively tested for vulnerabilities, using SAST, DAST and SCA prior to its initial release, any subsequent releases and periodically in order to attempt to identify any previously unidentified vulnerabilities (ISM-0402)
  2. Code reviews are utilised to ensure software meets Secure by Design principles and practices as well as secure programming practices (ISM-2060)
  3. Software developer-supported security-focused peer reviews are conducted on all critical and security-focused software components (ISM-2061)
  4. Unit testing and integration testing, covering both positive and negative use cases, are used to ensure code quality and security (ISM-2062)

7.1 Static Application Security Testing (SAST)

Requirements:

  • SAST tools integrated into development environment and CI/CD pipeline
  • Scans run on every commit or pull request
  • Minimum quality gates: No critical or high severity issues
  • False positives reviewed and documented
  • Tools: {{sast_tool}} (e.g., SonarQube, Checkmarx, Veracode)

7.2 Dynamic Application Security Testing (DAST)

Requirements:

  • DAST scans performed on staging environment before production deployment
  • Scans test running applications for vulnerabilities
  • Tests include authentication and authorization checks
  • Minimum quality gates: No critical issues
  • Tools: {{dast_tool}} (e.g., OWASP ZAP, Burp Suite, Acunetix)

7.3 Software Composition Analysis (SCA)

Requirements:

  • Continuous monitoring of third-party dependencies
  • Automated alerts for vulnerable dependencies
  • Regular dependency updates
  • License compliance checking
  • Tools: {{sca_tool}} (e.g., Snyk, Dependabot, WhiteSource)

7.4 Code Review Requirements

Requirements:

  • All code changes reviewed by at least one other developer
  • Security-critical code reviewed by security-trained developers
  • Review checklist includes security considerations
  • No self-approvals for production code
  • Documented review comments and resolutions

7.5 Penetration Testing

Requirements:

  • Annual penetration testing for production applications
  • Testing by qualified third-party security professionals
  • Scope includes: {{pentest_scope}}
  • Findings tracked and remediated within {{remediation_timeframe}}
  • Re-testing of critical findings

8. Web Application Development

ACSC ISM Control: ISM-1239, ISM-0971, ISM-1849, ISM-1850, ISM-1851, ISM-1424, ISM-1552, ISM-1241

Web applications follow OWASP guidelines:

  1. Robust web application frameworks are used in the development of web applications (ISM-1239)
  2. The OWASP Application Security Verification Standard is used in the development of web applications (ISM-0971)
  3. The OWASP Top 10 Proactive Controls are used in the development of web applications (ISM-1849)
  4. The OWASP Top 10 are mitigated in the development of web applications (ISM-1850)
  5. The OWASP API Security Top 10 are mitigated in the development of web APIs (ISM-1851)
  6. Content-Security-Policy, Hypertext Transfer Protocol Strict Transport Security and X-Frame-Options are specified by web server software via security policy in response headers (ISM-1424)
  7. All web application content is offered exclusively using HTTPS (ISM-1552)
  8. Output encoding is performed on all output produced by web applications (ISM-1241)

8.1 Session Management

ACSC ISM Control: ISM-2063, ISM-2064, ISM-2065, ISM-2066, ISM-2067

Secure session management practices:

  1. If supported, web application session cookies set the HttpOnly flag, Secure flag and the SameSite flag by default (ISM-2063)
  2. Web application session cookies contain only digitally signed opaque bearer tokens (ISM-2064)
  3. Web application session cookies using opaque bearer tokens that are not digitally signed use non-sequential random identifiers with a minimum of 128 bits of entropy, preferably 256 bits of entropy (ISM-2065)
  4. Web application sessions are centrally managed server side (ISM-2066)
  5. Web applications that support Single Sign On equally support Single Logout (ISM-2067)

8.2 OWASP Top 10 Mitigation

All web applications must mitigate the OWASP Top 10 risks:

  1. Broken Access Control - Implement proper authorization checks
  2. Cryptographic Failures - Use strong encryption for sensitive data
  3. Injection - Use parameterized queries and input validation
  4. Insecure Design - Follow Secure by Design principles
  5. Security Misconfiguration - Harden configurations, disable defaults
  6. Vulnerable and Outdated Components - Maintain updated dependencies
  7. Identification and Authentication Failures - Implement MFA and strong authentication
  8. Software and Data Integrity Failures - Verify integrity of code and data
  9. Security Logging and Monitoring Failures - Implement comprehensive logging
  10. Server-Side Request Forgery (SSRF) - Validate and sanitize URLs

9. Mobile Application Development

ACSC ISM Control: ISM-1922

The OWASP Mobile Application Security Verification Standard is used in the development of mobile applications (ISM-1922).

Requirements:

  • Follow OWASP MASVS requirements for mobile app security
  • Secure local data storage (encryption at rest)
  • Certificate pinning for network communications
  • Jailbreak/root detection (optional, based on risk)
  • Secure authentication and session management
  • Code obfuscation for sensitive logic
  • Runtime application self-protection (RASP) for high-risk applications

10. Artificial Intelligence Application Development

ACSC ISM Control: ISM-1923, ISM-1924, ISM-2072

AI applications implement specific security controls:

  1. The OWASP Top 10 for Large Language Model Applications are mitigated in the development of large language model applications (ISM-1923)
  2. Generative artificial intelligence applications evaluate user prompts to detect and mitigate adversarial inputs or suffixes designed to elicit unintended behaviour or assist in the generation of sensitive or harmful content (ISM-1924)
  3. Artificial intelligence models are stored in a file format that does not allow arbitrary code execution (ISM-2072)

Requirements:

  • Prompt injection attack mitigation
  • Output filtering and content moderation
  • Model access controls and versioning
  • Training data security and privacy
  • AI model integrity verification
  • Adversarial input detection

11. Vulnerability Disclosure Program

ACSC ISM Control: ISM-1616, ISM-1755, ISM-1756, ISM-1717

The company operates a vulnerability disclosure program:

  1. A vulnerability disclosure program is implemented to assist with the secure development and maintenance of products and services (ISM-1616)
  2. A vulnerability disclosure policy is developed, implemented and maintained (ISM-1755)
  3. Vulnerability disclosure processes, and supporting vulnerability disclosure procedures, are developed, implemented and maintained (ISM-1756)
  4. A 'security.txt' file is hosted for each of an organisation's internet-facing website domains to assist in the responsible disclosure of vulnerabilities in the organisation's products and services (ISM-1717)

11.1 Vulnerability Disclosure Policy

The company maintains a public vulnerability disclosure policy covering:

  • Purpose of the vulnerability disclosure program
  • Types of security research allowed and not allowed
  • How to report vulnerabilities: {{vulnerability_report_email}}
  • Expected response timeframes
  • Coordination and responsible disclosure expectations
  • Recognition for security researchers (if applicable)

11.2 security.txt Implementation

Requirements:

  • security.txt file hosted at: https://{{company_domain}}/.well-known/security.txt
  • File includes: Contact information, policy URL, acknowledgments page (optional)
  • File digitally signed and renewed annually
  • Monitored email address for vulnerability reports

12. Reporting and Resolving Vulnerabilities

ACSC ISM Control: ISM-1908, ISM-1754, ISM-1909

Vulnerabilities are handled responsibly:

  1. Vulnerabilities identified in software are publicly disclosed in a responsible and timely manner, including with Common Weakness Enumeration and Common Platform Enumeration information (ISM-1908)
  2. Vulnerabilities identified in software are resolved in a timely manner (ISM-1754)
  3. In resolving vulnerabilities, root cause analysis is performed and, to the greatest extent possible, entire vulnerability classes are remediated (ISM-1909)

Vulnerability Response Timeframes:

  • Critical vulnerabilities: Remediation within {{critical_vuln_timeframe}} (e.g., 7 days)
  • High vulnerabilities: Remediation within {{high_vuln_timeframe}} (e.g., 30 days)
  • Medium vulnerabilities: Remediation within {{medium_vuln_timeframe}} (e.g., 90 days)
  • Low vulnerabilities: Remediation within {{low_vuln_timeframe}} (e.g., 180 days)

Process:

  1. Vulnerability reported or discovered
  2. Triage and severity assessment (CVSS scoring)
  3. Root cause analysis
  4. Develop and test patch
  5. Deploy patch to production
  6. Public disclosure (coordinated with reporter)
  7. Update SBOM and security advisories

13. Change Management and Deployment

13.1 Deployment Security

Requirements:

  • Controlled deployment process with approvals
  • Automated deployment pipelines (CI/CD)
  • Rollback procedures for failed deployments
  • Production deployment windows: {{deployment_windows}}
  • Change approvals by: {{change_approver}}
  • Post-deployment verification testing

13.2 Configuration Management

Requirements:

  • Infrastructure as Code (IaC) for reproducible deployments
  • Configuration stored in version control
  • Secrets managed through secure vaults (not in source code)
  • Environment-specific configurations
  • Configuration drift detection and remediation

14. Third-Party Development and Outsourcing

When software development is performed by third parties:

Requirements:

  • Third-party developers bound by contract to follow this policy
  • Code ownership and intellectual property clearly defined
  • Security requirements included in contracts
  • Regular security assessments of third-party code
  • Access to development environments controlled and monitored
  • Code review of all third-party contributions
  • Compliance with {{company_name}} security standards

15. Compliance and Monitoring

15.1 Compliance Verification

Requirements:

  • Annual review of software development practices
  • Security metrics tracked and reported: {{security_metrics}}
  • Compliance audits of development processes
  • Tool coverage reports (SAST, DAST, SCA)
  • Training completion tracking

15.2 Security Metrics

The company tracks the following metrics:

  • Number of vulnerabilities by severity (SAST, DAST, SCA)
  • Mean time to remediate vulnerabilities
  • Code review coverage percentage
  • Security test coverage
  • Dependency update cadence
  • Security training completion rates

Staff Responsibilities

Staff (including interns and contractors) involved in software development are expected to:

  • Read, understand, and comply with this policy in its entirety
  • Complete required secure coding training
  • Follow secure development practices for their programming language
  • Participate in code reviews and security testing
  • Report security vulnerabilities immediately
  • Maintain security knowledge and skills current
  • Not introduce malicious code or backdoors
  • Protect source code and development credentials

Failure to comply may result in disciplinary action, up to and including termination of employment or contract.

Review

This policy will be reviewed {{default_policy_review}} or as needed based on:

  • Changes to software development practices
  • New security threats or vulnerabilities
  • Updates to ACSC ISM guidelines
  • Changes to technology stack or tools
  • Regulatory or compliance requirement changes

Enforcement & Waivers

These policies are important to us. Violation may result in disciplinary action, up to and including termination of employment. Only by consent of the {{company_name}}'s board of directors may a provision of this policy be waived.

ACSC ISM Alignment

This policy implements the ACSC Information Security Manual (ISM) Guidelines for Software Development (September 2025), covering:

  • Software development fundamentals (ISM-0400 series, ISM-2023 series)
  • Secure software development practices (ISM-0401, ISM-1238, ISM-2033 series)
  • Software security testing (ISM-0402, ISM-2060 series)
  • Web application development (ISM-0971, ISM-1239, ISM-1849 series)
  • Mobile application development (ISM-1922)
  • Artificial intelligence application development (ISM-1923, ISM-1924, ISM-2072)
  • Vulnerability disclosure program (ISM-1616, ISM-1717, ISM-1755)

Target Maturity: {{e8_target_maturity}}

Essential Eight Relevance

This policy supports Essential Eight controls:

  • E8 #1 (Application Control) - Through code signing and build security
  • E8 #2 (Patch Applications) - Through vulnerability management and dependency updates
  • E8 #3 (Configure Microsoft Office Macros) - Through secure application configuration
  • E8 #5 (Restrict Admin Privileges) - Through least privilege in application design
  • E8 #6 (Patch Operating Systems) - Through secure deployment on patched systems
  • E8 #8 (Regular Backups) - Through source code versioning and SBOM

Implementation Check

  1. Who owns this? {{policy_owner}}
  2. Are we doing it? {{implementation_status}}
  3. When will we check again? {{next_review_date}}

Board Oversight

Key Questions for Directors:

  1. Are we following secure development practices for all custom software?
  2. What critical vulnerabilities have been identified and how quickly were they remediated?
  3. Do we have adequate security testing coverage (SAST, DAST, SCA)?
  4. Are third-party dependencies regularly reviewed and updated?
  5. Do developers receive adequate security training?

Reporting: {{board_reporting_cycle}} review at board meetings

Further Information

ACSC Resources:

  • ISM Guidelines for Software Development: https://www.cyber.gov.au/ism
  • Secure by Design Foundations: https://www.cyber.gov.au/secure-by-design

OWASP Resources:

  • OWASP Top 10: https://owasp.org/Top10/
  • OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
  • OWASP Top 10 Proactive Controls: https://owasp.org/www-project-proactive-controls/
  • OWASP API Security Top 10: https://owasp.org/API-Security/
  • OWASP Mobile Security: https://mas.owasp.org/

Standards:

  • NIST Secure Software Development Framework (SSDF): https://csrc.nist.gov/pubs/sp/800/218/final
  • ISO/IEC 27034 Application Security