Skip to content
Software development
ASD ISMISM-2031

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 English

Use 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.

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 27001

ISO/IEC 27001: 3 mappings

  • A.8.25Secure development lifecyclePartially meets

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.