ASD ISM 2031 Secure system build tools implementation
What it says
Compilers, interpreters and build tools (including pipelines) that provide security features to improve executable file security are implemented and such security features are used.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse security features in compilers and build tools to secure your software's executable files.
This control is about using the security features in the tools that help create software, like compilers and build systems, to make sure the software is safe to use. It matters because if these features aren't used, it could lead to software that's vulnerable to hackers, causing data breaches or system failures that could damage a business's reputation and finances.
Free. Save your status, tasks and notes.
Why it matters
If build tools' security features are neglected, resulting software may harbour exploitable vulnerabilities, risking data loss and financial harm.
How to implement
The IT team should review the software development build tools currently in use.
They need to check if these tools have security features that can protect the software during the build process. Specific actions include researching documentation for any security options and settings in the compiler and enabling these features for active projects.
Software developers should regularly update their build tools and compilers.
By staying up to date, they ensure all recent security features and patches are included. This involves setting reminders for updates and subscribing to software announcements from the tools' providers to not miss important updates.
Managers overseeing software development projects should ensure that developers are aware of security features.
This could be done by organising training sessions or workshops about using security features within development tools effectively. Include practical examples specific to their ongoing projects to enhance understanding.
System owners should collaborate with the IT security team to conduct regular security audits of the software build process.
Schedule periodic checks where the build configuration is reviewed to make sure security features are enabled and functioning as expected. Document the findings and actions taken for future reference.
Procurement teams should include security feature checks as a criterion when purchasing new build tools.
This means ensuring that any new tools have robust security capabilities and are capable of integrating with existing security measures. Engage with vendors to provide demonstrations or trial versions to evaluate the security features before purchase.
Keep it running
Verify build scripts enable hardening flags (e.g., ASLR/DEP, stack protections) and routinely review pipeline logs to confirm these features are applied.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The list of software tools used in development projects: Request documentation that details all compilers and build tools in use.
Look at
The version numbers and the settings being used.
Good evidence
Will show tools with security features enabled and updated versions documented.
- Check 2 of 5What an auditor asks for
Ask for
Training records or materials: Request records or materials from developer training sessions focused on security features.
Look at
Schedules, sign-in sheets, and presentation materials.
Good evidence
Includes a recent session with practical, tool-specific security training documented.
- Check 3 of 5What an auditor asks for
Ask for
To see recent software build configuration files: Request access to the build configuration that developers use.
Look at
Specific settings or options enabled for security purposes.
Good evidence
Will show that security options like code signing or encryption are turned on.
- Check 4 of 5What an auditor asks for
Ask for
A recent internal audit report on build processes: Request a copy of any recent security review of the build process.
Look at
Findings and actions taken to improve security.
Good evidence
Will be a detailed report with identified issues and remedial actions completed.
- Check 5 of 5What an auditor asks for
Ask for
Procurement documentation: Request any recent requests for proposal (RFPs) or purchase records.
Look at
Criteria that mention security features.
Good evidence
Includes clear references to security as a requirement in the selection process.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.25.
Annex A 8.25 requires organisations to establish and apply rules across a secure development lifecycle for software and systems. ISM-2031 is a specific secure-SDLC rule requiring compilers/interpreters/build tools and pipelines to use security features that harden produced executables. Annex A 8.25 is broader because it covers many SDLC practices beyond build-tool hardening (e.g. requirements, design, review, testing, release).
This control partially meets A.8.27.
ISM-2031 requires organisations to implement secure build tools and ensure their security features are used to harden executables. ISO/IEC 27001:2022 Annex A 8.27 requires secure system architecture and engineering principles to be established and applied, which can include principles for secure build, reproducibility, and compiler-based mitigations. Annex A 8.27 is broader and higher-level across engineering practices, while ISM-2031 is a specific technical instantiation focused on build tooling and compiler/interpreter security features.
This control partially meets A.8.28.
ISM-2031 requires organisations to implement and use build-tool security features (e.g. compiler/linker hardening, pipeline protections) to strengthen executable security. ISO/IEC 27001:2022 Annex A 8.28 requires secure coding principles to be applied in software development, and hardened compilation/build settings reduce the impact of coding errors (such as memory corruption) by adding exploit mitigations. Annex A 8.28 primarily addresses how code is written, while ISM-2031 addresses how software is built and packaged into executables.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.




