Skip to main content

This section of the ISM provides guidance on application development.

Types of application development

These guidelines are applicable to both traditional application development activities as well as mobile application development activities.

Development environments

Segregating development, testing and production environments can limit the spread of malicious code and minimises the likelihood of faulty code in a production environment.

Security Control: 0400; Revision: 5; Updated: Aug-20; Applicability: O, P, S, TS
Development, testing and production environments are segregated.

Security Control: 1419; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
Development and modification of software only takes place in development environments.

Security Control: 1420; Revision: 2; Updated: Sep-18; Applicability: O, P, S, TS
Information in production environments is not used in testing or development environments unless the testing or development environments are secured to the same level as the production environments.

Security Control: 1422; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
Unauthorised access to the authoritative source for software is prevented.

Secure software design

Threat modelling is an important part of secure software design. Threat modelling identifies at risk components of software, enabling security controls to be identified to reduce security risks.

Security Control: 1238; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
Threat modelling and other secure design techniques are used to ensure that threats to software and mitigations to those threats are identified and accounted for.

Secure programming practices

Once a secure software design has been identified, secure programming practices should be followed during software development activities.

Security Control: 0401; Revision: 4; Updated: Oct-19; Applicability: O, P, S, TS
Platform-specific secure programming practices are used when developing software, including using the lowest privilege needed to achieve a task, checking return values of all system calls, validating all inputs and encrypting all communications.

Software testing

Software testing can lessen the risk of security vulnerabilities in software being introduced into a production environment. Software testing can be performed using both static testing, such as code analysis, as well as dynamic testing, such as input validation and fuzzing. Vulnerability scanning tools can also assist in the detection of known security vulnerabilities, such as out of date or vulnerable dependencies. Using an independent party for software testing will remove any bias that can occur when a software developer tests their own software.

Security Control: 0402; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
Software is tested for security vulnerabilities by software developers, as well as an independent party, before it is used in a production environment.

Vulnerability disclosure program

Implementing a vulnerability disclosure program, based on responsible/coordinated disclosure, can assist organisations, vendors and service providers to improve the security of their products and services as it provides a way for security researchers, customers and members of the public to responsibly notify them of potential security vulnerabilities in a coordinated manner. Furthermore, following the verification and resolution of a reported security vulnerability, it can assist organisations, vendors and service providers in notifying their customers of any security vulnerabilities that have been discovered in their products and services and any recommended security patches, updates or mitigations.

A vulnerability disclosure program should include processes to receive, verify, resolve and report on security vulnerabilities disclosed by both internal and external sources. In support of this, a vulnerability disclosure policy should be made publicly available that covers:

  • the purpose of the vulnerability disclosure program
  • the types of security research that are allowed
  • the types of security research that are not allowed
  • how to report potential security vulnerabilities
  • the actions that will be taken on receiving notification of potential security vulnerabilities and indicative timeframes for these actions
  • any expectations regarding the public disclosure of verified security vulnerabilities
  • any recognition finders of verified security vulnerabilities will receive.

Finally, the Australian Cyber Security Centre (ACSC) encourages security researchers, customers and members of the public to responsibility report security vulnerabilities directly with organisations, vendors and service providers. However, the ACSC recognises that this is not always practical, initial attempts at communication may be unsuccessful or the person making the report may not wish to do so directly. In such cases, security vulnerabilities can be reported to the ACSC as an independent coordinator at https://www.cyber.gov.au/acsc/report.

Security Control: 1616; Revision: 0; Updated: Aug-20; Applicability: O, P, S, TS
A vulnerability disclosure program is implemented to assist with the secure development and maintenance of products and services.

Further information

An example of a secure development life cycle model, known as the Trustworthy Computing Security Development Lifecycle, is available at https://docs.microsoft.com/en-au/previous-versions/ms995349(v=msdn.10).

Further information on secure coding practices is available at https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=21274.

Further information on implementing a vulnerability disclosure program can be found in: