When a South Australian agency, council or business commissions a portal, an app or an API, security is usually covered by one line in the brief: “the solution must be secure”. That line is hard to test, hard to price and easy to argue about at go-live. A better approach is to agree, up front, which recognised practices the supplier will follow and what evidence they will hand over. This guide explains the main reference points, OWASP Top 10, the OWASP Application Security Verification Standard (ASVS), the NIST Secure Software Development Framework and software supply chain controls, and how to turn them into practical requirements for a project of any size. It is general guidance, not a compliance assessment; check your own policies and contract terms.
Why “make it secure” isn’t enough
Most application security problems are not exotic. They are missing access checks, settings left at their defaults, outdated libraries, secrets committed to code, and errors that reveal too much. They appear when nobody owns security across the whole lifecycle: design, coding, build, testing, release and support. Clear requirements fix that by making security part of the scope, the plan and the acceptance criteria rather than a hope.
The reference points worth knowing
- OWASP Top 10 (2025 edition). An awareness list of the most critical web application risks. The 2025 list puts broken access control first, followed by security misconfiguration and software supply chain failures, and adds mishandling of exceptional conditions. It is a good training and prioritisation tool, but OWASP itself says it is not a checklist or a standard.
- OWASP ASVS (version 5.0). A testable set of security requirements for web applications and APIs, organised into three levels. Level 1 is a baseline for most applications, Level 2 suits applications that handle personal or sensitive information, and Level 3 is for the highest-risk systems. Because each requirement is verifiable, ASVS works well in a tender or contract.
- NIST Secure Software Development Framework (SP 800-218). Describes the practices a mature supplier follows: prepare the organisation, protect the software, produce well-secured software and respond to vulnerabilities. Useful for asking a supplier how they work, not just what they deliver.
- Australian guidance. The Information Security Manual (ISM) includes guidelines for software development, the Essential Eight covers patching and hardening of what you run, and SA Government buyers apply the SA Cyber Security Framework (SACSF) to suppliers. See our SACSF guide for ICT suppliers and Essential Eight guide.
Security requirements to put in the brief
You don’t need a long schedule. For most council and small agency projects, these requirements cover the important ground:
- Pick an ASVS level. State that the application must meet ASVS Level 1, or Level 2 if it handles personal, financial or sensitive information, with any exclusions agreed in writing.
- Threat model the design. Ask for a short threat model before build starts and an update when the design changes. Our STRIDE and MAESTRO threat modelling guide explains a lightweight way to do this, including for AI features.
- Identity and access. Single sign-on or phishing-resistant multi-factor authentication for staff, least-privilege roles, and server-side access checks on every request.
- Data protection. Encryption in transit and at rest, Australian hosting where required, data minimisation, and no real personal information in test environments.
- Logging and alerting. Security events logged centrally, without passwords or personal details in the logs, with alerts someone actually receives.
- Error handling. Fail safely: no stack traces or system details shown to users, and no partial transactions left behind.
Build security into the pipeline
Manual reviews at the end of a project find problems too late. A modern delivery pipeline runs most checks automatically on every change:
- Code review by a second developer before anything merges, with protected main branches.
- Static analysis (SAST) to catch common coding flaws early.
- Dependency scanning to flag libraries with known vulnerabilities or unsuitable licences.
- Secret scanning so keys and passwords never reach the repository.
- Infrastructure as code checks for insecure cloud settings before they are deployed.
- Dynamic testing (DAST) against a test environment, plus accessibility and regression tests.
Our Learn architecture for a CI/CD and infrastructure as code pipeline shows where each of these checks sits.
Software supply chain: know what you are running
Most applications are largely made of open-source components, frameworks and cloud services. Supply chain failures now sit near the top of the OWASP list because a single compromised or outdated package can affect thousands of systems. Practical controls include:
- A software bill of materials (SBOM) in a standard format such as CycloneDX or SPDX, delivered with each release so you know which components and versions are in use.
- Pinned, trusted sources for packages and container images, with lock files committed and updates reviewed rather than pulled in blindly.
- Protected build systems: least-privilege pipeline credentials, short-lived cloud access instead of stored keys, and signed or traceable release artefacts.
- An update routine after go-live, so dependencies are patched on a schedule and urgently when a serious vulnerability is announced. Our patch and vulnerability management guide covers the operational side.
Testing and acceptance evidence
Ask for evidence you can file with the project records, not just a verbal assurance. A sensible go-live pack includes the threat model, the ASVS checklist with results, pipeline scan results with any accepted risks explained, an independent penetration test for internet-facing or higher-risk systems, and confirmation that findings rated high or critical are fixed or formally accepted by the business owner. Our software testing and UAT guide explains how security testing fits alongside user acceptance testing.
After go-live: responding to vulnerabilities
Security doesn’t end at launch. Agree in the support contract how quickly the supplier will assess and fix newly reported vulnerabilities, who is told, and how fixes are tested and released. Publish a simple way for people to report security issues, such as a security.txt file, and keep the SBOM current so you can quickly answer the question “are we affected?” when the next widely reported vulnerability appears.
Questions to ask a software supplier
- Which ASVS level will you build and test to, and how will you show it?
- Who reviews code before it merges, and what automated security checks run in your pipeline?
- Will you provide an SBOM with each release and keep dependencies updated after go-live?
- How do you manage secrets and access to our cloud accounts and repositories?
- Who owns the code, pipelines and documentation at the end of the engagement?
- How do you handle a vulnerability reported after launch, and how fast?
A practical starting plan
- Before the brief: classify the data the application will hold and choose an ASVS level.
- In the brief: include the requirements above, the evidence you expect at go-live and the support expectations.
- During design: run a short threat modelling workshop and agree the security architecture.
- During build: confirm the pipeline checks are running and review findings at each sprint demo.
- Before go-live: review the evidence pack and penetration test results, and accept residual risks in writing.
- After go-live: keep dependencies patched, the SBOM current and the vulnerability process tested.
How EITSAA can help
EITSAA is an Adelaide-owned technology company working with SA councils, agencies and businesses. We build applications with threat modelling, automated security checks, SBOMs and handover documentation as part of delivery, and we can review an existing application or brief against ASVS. Get a quote for secure application development or a security review or call 0402 401 584, Monday to Friday, 9am to 5:30pm. Learn more about our application development, DevOps and cloud engineering and managed IT and cyber security services.