← VCE Software Development U4O2

ISM Guidelines for Software Development

ISM guidelines that set security expectations for how software is designed, coded, tested and released, such as secure coding, separate environments, code review and testing.

Part of: VCE Software Development - U4O2 - Cyber Security: secure software development practices — Module 97

Understanding ISM Guidelines for Software Development in VCE Software Development U4O2

What it does: Validating input is a secure coding practice that the ISM software development guidelines expect developers to follow to prevent attacks such as injection. The guidelines cover the whole lifecycle: how software is designed, written, tested and released. Separate environments stop untested code and test data from affecting live systems and real data. Version control keeps a history of changes, and code review helps find security flaws before release. Third-party code can contain vulnerabilities or malicious content, so it must be assessed and maintained. Testing before release finds and fixes vulnerabilities early, rather than reacting after damage is done. The ISM sets security expectations. It does not dictate a particular language or tool.

Common mistakes: Joining user input onto the query allows SQL injection. Secure coding passes it as a parameter: db.execute(sql, (name,)). Invalid input must be rejected. With pass the program carries on with unvalidated data. It should stop with exit().

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add ISM Guidelines for Software Development to a class →

This module's key terms are also in a printable crossword (Modules 97–130) and word search (Modules 49–130).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
The ISM Guidelines for Software Development cover only the final release of software, not how it is designed or written.
FalseTrue
Matches
Developers push changes straight to production with no peer review or version control
↓
Skips version control and code review, which the ISM guidelines expect so that changes are tracked and checked
Applying
Meanings
Term
ISM Guidelines for Software Development
Meaning
ISM guidelines that set security expectations for how software is designed, coded, tested and released, such as secure coding, separate environments, code review and testing.
Practice
BEGIN SecureRelease
Testing
Gaps
IF isValid(userInput) THEN
Check Answer
Spots
3sql += 'WHERE name = ?'
4db.execute(sql + name)

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Squirrel' badge — Module Hoarder, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. The ISM Guidelines for Software Development cover only the final release of software, not how it is designed or written.
A. False ✓
B. True
The guidelines cover the whole lifecycle: how software is designed, written, tested and released.
2. Which approach matches the ISM guidelines on environments?
A. Test new code directly in the production environment
B. Keep development, testing and production environments separate ✓
Separate environments stop untested code and test data from affecting live systems and real data.
3. Which practice is part of secure design and coding under the ISM guidelines?
A. Trusting all user input to keep the code short
B. Following secure coding practices and validating all input ✓
Secure coding includes input validation, which helps prevent attacks such as SQL injection.
4. Under the ISM guidelines, how should changes to code be handled?
A. Store code in version control and have changes reviewed ✓
B. Let each developer edit the live code without records
Version control keeps a history of changes, and code review helps find security flaws before release.
5. A team adds an open-source library to its app. What fits the ISM guidelines on third-party code?
A. Check the library comes from a trusted source and keep it updated ✓
B. Assume the library is safe because many people use it
Third-party code can contain vulnerabilities or malicious content, so it must be assessed and maintained.

Match the Pairs

ISM Guidelines for Software Development → Security expectations for how software is designed, written, tested and released
Development, testing and production kept in separate environments → An ISM-aligned practice that stops untested code and live data from being mixed or exposed
The ISM expects secure design and coding practices, such as validating all user input → if not username.isalnum(): reject()
The ISM expects security testing of software before it is released → run_security_tests(build) before release
Developers push changes straight to production with no peer review or version control → Skips version control and code review, which the ISM guidelines expect so that changes are tracked and checked
import any_package # downloaded from an unknown site, never checked → Uses third-party code without checking it is trusted or secure, which the ISM guidelines expect to be managed

Key Term

ISM Guidelines for Software Development
ISM guidelines that set security expectations for how software is designed, coded, tested and released, such as secure coding, separate environments, code review and testing.

Fill in the Blanks

1. IF NOT isValid(userInput) THEN reject(userInput) END IF
Hint: Type the logical operator that reverses the validation result so bad input is rejected (secure coding).
2. IF environment = "testing" THEN connect(testDatabase) END IF
Hint: Type the comparison operator that checks the current environment is the testing one, so test code never touches production data.
3. IF reviewed(changes) AND testsPassed THEN merge(changes) END IF
Hint: Type the logical operator that requires both code review and passing tests before changes are merged.
4. FOR EACH package IN dependencies IF NOT verified(package) THEN blockInstall(package)
Hint: Type the loop variable that represents each third-party item being checked for trustworthiness.
5. result ← runSecurityTests(build) IF result.failed > 0 THEN blockRelease(build)
Hint: Type the comparison operator that detects one or more failed security tests before release.

Spot the Error

Question 1
A name = input('Name: ')
B sql = 'SELECT * FROM users '
C sql += 'WHERE name = ?'
D db.execute(sql + name)
Line D — Joining user input onto the query allows SQL injection. Secure coding passes it as a parameter: db.execute(sql, (name,)).
Question 2
A age = input('Age: ')
B if not age.isdigit():
C print('Invalid age')
D pass
E age = int(age)
Line D — Invalid input must be rejected. With pass the program carries on with unvalidated data. It should stop with exit().
Question 3
A ENV = 'testing'
B DB_URL = 'prod-db.local'
C if ENV == 'testing':
D use_fake_data()
Line B — The testing environment must be kept separate from production. It should use the test database, 'test-db.local', not the live one.
Question 4
A git checkout -b fix-login
B git add login.py
C git commit 'Fix login bug'
D git push origin fix-login
E # open pull request for review
Line C — git commit needs the -m flag before the message. It should be git commit -m 'Fix login bug', which records a clear change in version control.
Question 5
A request_review(pull_request)
B result = get_review_result()
C if result != 'approved':
D merge(pull_request)
Line C — The condition is reversed, so code that was not approved would be merged. Code review requires result == 'approved' before merging.

Student with a class code? Join your class →