Secure by Design Software Development Australia

Trusted by established organisations across Australia

Government, health, energy, education, finance and enterprise.

Conduct design studio meeting room with team collaborating

When a customer asks which security standard you follow

The question often comes in a security questionnaire, a tender or a contract, and which standard applies depends on the product and who is buying it. OWASP ASVS is often named for web applications and APIs, the ASD Information Security Manual (ISM) and Essential Eight for government systems, and IEC 62443 for devices and systems that monitor or control equipment. Whichever is named, the evidence has to come from the code, the architecture and the release process, whether the product is already in use or still being designed.

We are the engineering team that changes all three. We find the gaps between your product and the standard, close them, and document the evidence as we go. The formal judgement belongs to your assessor or certification body, and we work alongside them from the first gap list to the final evidence pack.

Bringing an existing product up to a security standard

An uplift can start with that questionnaire. We help you triage it, separating the answers you can evidence today from the ones that need changes to the code or the release process, and that list feeds the gap assessment. From there, a product security uplift runs in five stages, and each stage produces a record you can show a customer.

Gap assessmentWe review the code, architecture, dependencies and release process against the named standard, then hand you a ranked gap list and a costed remediation plan.
Remediation buildOur engineers close the gaps in your codebase. Typical changes cover authentication and access control, secrets handling, dependency upgrades, logging and audit records, encryption, and SBOM generation in the release pipeline.
Staged rolloutWe plan the release of the upgraded product one site or user cohort at a time, with health checks and a tested rollback at each stage. For a device fleet, the fixes go out through the staged updates our IoT integration services team runs.
Evidence packEach requirement is mapped to the design element, test record or scan that shows it, ready for your customer’s security team, your assessor or a certification body.
Ongoing supportStandards are revised and new vulnerabilities appear. We keep the product patched and the evidence current under an SLA through our software support and maintenance service.

Conduct team working on Melbourne rooftop with city skyline

Fixing the findings from a pen test or security review

A penetration test, a customer security review or a vulnerability scan ends with a list of findings ranked by severity, often with a date by which they must be closed to stay compliant. Our senior developers work through the findings in sprints alongside your team, in new code or in a legacy product your organisation still relies on, turning each one into a change in the code, the configuration or the infrastructure.

Our vulnerability remediation traces each finding to its root cause, so the whole class of weakness is fixed wherever it appears in the codebase. The remediation plan pairs each fix with a test that proves it and a check in a staging environment before release. When your tester returns for the retest, each finding in their report has a matching fix record. Our guide to pen test remediation for a legacy product sets out the steps from ranking the findings to closing the retest.

We work with the tester or assessor you choose. They find the gaps, and we close them without breaking the features your users rely on. Once the retest is closed, we can add checks to your release pipeline that catch the same weaknesses if they return, and support the product from there.

The standards and rules we design for

The standard a product is measured against shapes the work. These are standards and rules that customers and tenders raise, from government agencies to energy and infrastructure operators.

IEC 62443Security for industrial automation and control systems. Part 4-2 covers devices and components, part 3-3 the whole system.
OWASP ASVSA verification checklist for web applications and APIs, with three levels of rigour.
OWASP Top 10 and CWE Top 25The most critical web application security risks and the most dangerous software weaknesses.
ASD ISMA cyber security framework for IT and operational technology systems, including controls for software development.
Essential EightASD’s eight priority mitigation strategies, measured by maturity level across an organisation.
NIST SSDFThe Secure Software Development Framework (NIST SP 800-218), a core set of practices that can be added to any development lifecycle.
SOCI ActResponsible entities for specified critical infrastructure assets must address supply chain hazards in a risk management program, which reaches their software and device suppliers.
Cyber Security Act 2024Smart device rules for consumer-grade connected products sold in Australia, in force since March 2026.
EU Cyber Resilience ActSecurity requirements for products with digital elements sold into the European Union.
Privacy Act 1988Australian Privacy Principle 11 covers how personal information is protected from misuse and loss.

For a connected product, our guide to IEC 62443 for edge devices explains which parts of the series apply.

Conduct team collaborating in the Melbourne studio on social impact digital products

Building secure by design from the first sprint

On a new platform we agree the security requirements with you, model the threats to the system and its data, and decide the verification level the product will be tested to. For web applications and APIs we usually test to OWASP ASVS level 2. ASVS is the verification standard the ISM names for web application development.

We then set up secure defaults. Each account gets the least privilege its role needs, administrative access requires multi-factor authentication, personal information is collected only where the service needs it and is encrypted in storage and in transit, and security events are logged in a form an incident responder can use. Privacy by design sits in the same conversation, so Privacy Act obligations shape the data model before it is built.

We set these defaults on the platforms we build through our custom software development service, whatever the stack, from .NET and Node.js platforms on Azure or AWS to mobile apps in Swift, Kotlin or React Native. They follow the approach in ASD’s Secure by Design guidance for software makers.

A secure software development lifecycle with DevSecOps in the pipeline

We set up a secure software development lifecycle based on the NIST SSDF and the software development controls in the ISM. Its security checks run as changes are made, so many weaknesses are caught in the pull request, where they are quickest to fix. The lifecycle we build with you includes these practices.

Threat modellingThreats to each component and data flow are mapped at design and revisited when the architecture changes.
Secure design reviewA second engineer reviews security decisions before they are built, and each decision is recorded.
Version control and code reviewCode lives in Git with protected branches, and changes are reviewed by someone other than their author before they merge.
Static analysis in CISAST tools scan pull requests for code weaknesses, including many of the classes in the CWE Top 25 and OWASP Top 10.
Dependency and secret scanningThird-party packages are checked for known vulnerabilities and commits are checked for leaked credentials.
SBOM generationBuilds produce a software bill of materials in CycloneDX or SPDX format.
Signed releasesRelease artefacts are signed so servers and devices can verify what they install.
Security testing before releaseAutomated security tests and a release check run before a version reaches production.

DevSecOps brings these practices into the way software is delivered and run, and automation makes them repeatable. The scanners, signing steps and release gates live in the CI/CD pipeline our DevOps consulting team builds and runs, whether that is GitHub Actions, Azure DevOps or another platform, so no security check depends on someone remembering to run it.

Conduct team discussing ideas in studio lounge

How we assess a codebase

Before an uplift, before a launch, or when we start supporting a platform another team built, we score the code. The review reports against the nine ISO/IEC 25010 product quality characteristics, from security and reliability to maintainability, safety and interaction capability (which covers accessibility). The security checks draw on OWASP ASVS, the CWE Top 25, the ISM, the NIST SSDF and, for devices, IEC 62443-4-2. Maintainability and performance are measured with the ISO/IEC 5055 weakness lists and counting method.

Every mark needs evidence, such as a file and line, a tool report or a test record. A second review pass, run separately, re-checks every critical item and every passing mark before a score is reported. The score shows where the code stands and where to spend effort first. It is a guide for planning, separate from any certification.

Secure software for government agencies

For agency systems we build to the ISM controls that apply to the system, and we design for the Essential Eight mitigations many agencies are measured on, such as multi-factor authentication, restricted administrative privileges and timely patching. Agencies can engage our team through the five Australian government panels Conduct is on (GovCMS, the DTA’s Digital Marketplace Panel 2, the Victorian eServices Register, DJCS Solution Delivery and DoH Solution Delivery). We have designed, built and supported software since 2008 with an in-house Australian team, and our government sector page covers our agency projects and panels.

Asked for evidence against a security standard, or starting a new platform? Talk to the engineers who will plan and build it.

Talk to a senior engineer

Common questions about secure by design software

What does secure by design mean for software?+−

Secure by design means security decisions are made when the software is designed, before it is built. The team agrees security requirements, models threats, sets secure defaults such as least privilege and multi-factor authentication, and plans logging and updates from the start. ASD and its international partners publish secure by design guidance that moves much of the burden of product security from customers to the software maker.

Can you certify our product to IEC 62443 or the ISM?+−

No. Formal assessment and certification are done by independent assessors and certification bodies. We do the engineering around them. We assess the gaps, build the fixes, roll the upgraded product out and prepare an evidence pack that maps each requirement to a design element, test or scan. We then work alongside your assessor to answer questions and close anything they raise.

What is a secure software development lifecycle?+−

A secure software development lifecycle (SSDLC) builds security practice into every stage of delivery. It typically covers security requirements, threat modelling and design review, secure coding and code review, automated scanning, security testing before release, signed releases and a process for fixing vulnerabilities once the software is live. Common references include the NIST Secure Software Development Framework, the ASD ISM and, for industrial products, IEC 62443-4-1.

What is the difference between DevSecOps and a secure SDLC?+−

A secure SDLC is the whole set of security practices from requirements to retirement, including design decisions that no tool can make. DevSecOps brings those practices into DevOps ways of working, and much of it runs as automation in the delivery pipeline, with static analysis, dependency and secret scanning, SBOM generation, signing and release gates on each change. A product needs both, and the automation keeps the checks consistent from one release to the next.

What is an SBOM and who asks for one?+−

A software bill of materials (SBOM) is a machine-readable list of every component in a release, with versions, suppliers and licences, usually in CycloneDX or SPDX format. Enterprise and government buyers ask for one in security questionnaires and tenders. The EU Cyber Resilience Act brings in a requirement for manufacturers to draw one up, and ASD co-authored the 2026 SBOM minimum elements guidance with CISA.

How long does a security gap assessment and uplift take?+−

It depends on the size of the codebase, the standard and level your customer asked for, how much automated testing already exists, and how many devices, sites or users the rollout has to reach. The gap assessment comes first and gives you a ranked gap list with a costed plan, so the timeline is set from the gaps found in your product.

Can you uplift a product another team built?+−

Yes. An uplift often starts with code another team wrote. We begin with a review of the codebase, documentation, build and deployment, then run the gap assessment against the named standard. Once the upgraded product is rolled out, we can keep supporting it under an SLA, or hand it back to your own team with the documentation and evidence in place.

Does IEC 62443 apply to our product?+−

If your product is a connected device, edge controller or gateway that monitors or controls equipment in an industrial or commercial setting, IEC 62443 is the international series written for it. Part 4-2 covers the device and part 3-3 the whole system. Many consumer-grade connected products sold in Australia, such as IP cameras and home routers, also fall under the smart device rules of the Cyber Security Act 2024. Our IEC 62443 journal guide explains how to tell.

Can you fix pen test findings in a legacy product?+−

Yes, including legacy products another team built. A pen test report is a common starting point for an uplift. We rank the findings by risk, trace each one to its root cause and fix that class of weakness across the codebase. The remediation plan pairs each fix with a test and a staging check before release, and we coordinate the retest with your tester so the report can be closed.

Can you review our app’s security before it launches?+−

Yes. We review the code, sign-in and permissions, how each customer’s data is kept apart, and the deployment, monitoring and backups. You get a ranked list of what must be fixed before launch, with the evidence for each item, scored the same way as every codebase we assess.