Security built into how your software ships
For teams that build or buy software, the requirements, review gates and dependency rules that stop the same findings appearing in every penetration test.
- Reference standards
- OWASP ASVS and NIST SP 800-218 (SSDF)
- For
- In-house teams, and companies buying software from vendors
- Gates
- Four, inside the workflow you already use
- ECC hooks
- Cybersecurity in IT project management, and web application security
- Delivery
- Remote
Secure development advisory sets the security requirements, review points and tooling rules for a team that builds software, in-house or through a vendor. We write the requirements against a published standard, add security gates to the workflow you already use, and specify what the application test should cover. Your developers, your vendor or ITF Digital build.
- 01 Call
- 02 Scope
- 03 Read
- 04 Register
- 05 Documents
- 06 Plan
Security built into how your software ships sits at step 5 of how an engagement runs. You receive the document set.
The same findings, every year
Missing authorisation checks on an API. A secret key committed to a code repository. A library three years out of date. Error messages that print the database query.
Each gets fixed where the tester found it, and the next test finds it somewhere else.
These are process failures showing up as code. They are fixed at the source by deciding, in writing, what the software must do, and checking at each gate that it does.
Four gates in the workflow you already have
| Gate | What happens | Record |
|---|---|---|
| Requirements, before design | Security requirements chosen from an OWASP ASVS level suited to the application. | The security requirements specification |
| Design review, before build | Data flows and trust boundaries drawn; the threats that matter listed with their controls. | A one-page threat model per feature that handles sensitive data or money |
| Build, every change | Your pipeline runs dependency and secret scanning; reviewers use a short security checklist. | Pipeline results and review records |
| Release, before major releases | Pre-release checks, and an application test for major changes, scoped by us and run by a provider. | The release checklist and the provider's report |
Documents your developers work from
The security requirements specification
At a stated ASVS level, with the reason for that level written into it.
The secure development procedure
The four gates, what each checks and the record each leaves.
Threat model worksheets
One page each, for features that handle sensitive data or money.
Dependency and secret management rules
What the pipeline checks, and what blocks a release.
The vendor contract security schedule
For software you buy: the requirements written as contract terms.
The application test scope
Ready to send to testing providers, so their quotes cover the same thing.
A customer portal, bought from a software house
A company is commissioning a customer portal from an outside software house. The portal will hold customer accounts and payment history.
We write the security requirements from ASVS, at the level suited to an application holding personal and financial data, and they go into the contract as a schedule.
The software house's design includes a single API key shared by every mobile app user, which the design review catches before any code exists. The build gate adds dependency and secret scanning to the software house's pipeline, with a rule that high-severity issues block a release. Before go-live, we scope the application test and the company contracts a provider.
The company holds a requirements specification, a contract schedule, the threat model, the pipeline rules, the test scope and the provider's report.
Build, buy, or both
Your pipeline, our rules
The tooling in the build gate is run by your team inside your own pipeline. We choose what it should check and what blocks a release. Typical rules:
- A secret found in the code blocks the release until the secret is rotated, not just deleted, because it is already in the repository history
- A vulnerable library with a known, published exploit blocks the release
- The same library with no known exploit becomes a ticket with a date
The requirements go in the contract
Most organisations do not build; they buy. The requirements then belong in the contract: the ASVS level the software must meet, how fast the vendor fixes vulnerabilities by severity, an independent application test before go-live, a list of the third-party components the software includes, and what happens to your data when the contract ends. Acceptance testing checks the security requirements alongside the functional ones.
Where ECC reaches your developers
For organisations in ECC scope, two subdomains land on the development team: cybersecurity in IT project management, and web application security. Both need evidence from the development process itself, which the gate records provide.
Requirements from Cyber, build from Digital
ITF Digital builds software. ITF Cyber writes the security requirements and the gates. When Digital builds for you, it builds to these requirements, and the application test before go-live is run by an outside provider, so the check comes from someone other than the builder.
What CTOs and product owners ask
Do you review our source code for vulnerabilities?
No. Reviewing code for vulnerabilities is testing work, done by your reviewers against the checklist or by a provider. We set the checklist and the rules.
We use agile, with two-week sprints. Does this slow us down?
The gates sit inside the flow you already have. Requirements are written once per application, not per sprint, and the build gate is automated.
Which ASVS level do we need?
It depends on what the application holds. Most business applications with personal or financial data sit at the middle level. We state the level and the reason in the specification.
Can ITF Digital build it and you check it?
Digital can build it to these requirements. The independent check before go-live is still an outside provider's test, which we scope.
What drives the cost?
The number of applications, whether you build or buy, and how much of your current workflow is written down.
Where this connects
Commissioning a penetration test
The buyer's side of the application test at the release gate.
Read moreServiceSecurity policies and governance
The secure development policy these gates put into practice.
Read moreITF DigitalApp development, ITF Digital
Internal tools and portals, built to the requirements written here.
Read moreITF DigitalWebsites and web apps, ITF Digital
Public sites and web applications, which can be built to the same requirements.
Read moreITF DigitalHow a build runs, ITF Digital
The delivery steps these four gates sit inside.
Read morePart of one system
Every division keeps records to the same standard, so the second one you need works the way the first one did.
Write the requirements before the first line of code
One specification per application, gates inside your existing workflow, and a test scope ready for providers.