ISM Guidelines for Software Development

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

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

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

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

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

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

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

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

Definitions

ISM Guidelines for Software Development

Fill in the Blanks

Complete each line of code by filling in the missing parts.

IF ___ isValid(userInput) THEN reject(userInput) END IF

IF environment _ "testing" THEN connect(testDatabase) END IF

IF reviewed(changes) ___ testsPassed THEN merge(changes) END IF

FOR EACH package IN dependencies IF NOT verified(_______) THEN blockInstall(package)

result ← runSecurityTests(build) IF result.failed _ 0 THEN blockRelease(build)

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A name = input('Name: ')

B sql = 'SELECT * FROM users '

C sql += 'WHERE name = ?'

D 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)

Question 3

A ENV = 'testing'

B DB_URL = 'prod-db.local'

C if ENV == 'testing':

D use_fake_data()

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

Question 5

A request_review(pull_request)

B result = get_review_result()

C if result != 'approved':

D merge(pull_request)

Answer Key

ISM Guidelines for Software Development

Section A: Quick Questions

A — False

B — Keep development, testing and production environments separate

B — Following secure coding practices and validating all input

A — Store code in version control and have changes reviewed

A — Check the library comes from a trusted source and keep it updated

Section B: 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

Section C: Definitions

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.

Section D: Fill in the Blanks

IF NOT isValid(userInput) THEN
    reject(userInput)
END IF

IF environment = "testing" THEN
    connect(testDatabase)
END IF

IF reviewed(changes) AND testsPassed THEN
    merge(changes)
END IF

FOR EACH package IN dependencies
    IF NOT verified(package) THEN
        blockInstall(package)

result ← runSecurityTests(build)
IF result.failed > 0 THEN
    blockRelease(build)

Section E: Spot the Error

D — Joining user input onto the query allows SQL injection. Secure coding passes it as a parameter: db.execute(sql, (name,)).

D — Invalid input must be rejected. With pass the program carries on with unvalidated data. It should stop with exit().

B — The testing environment must be kept separate from production. It should use the test database, 'test-db.local', not the live one.

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.

C — The condition is reversed, so code that was not approved would be merged. Code review requires result == 'approved' before merging.