Cloud and security · Application security
Application security and secure SDLC
We provide application security and secure SDLC for enterprises and product companies: security requirements and threat modelling at design time, secure coding standards and reviews, automated and manual testing, penetration testing, vulnerability management and the training and tools that help developers write safer code. Security becomes part of how software is designed and built, not a gate at the end, and you own the standards, the tooling and the code.
Checklist · Industrial security
OT security, NIS2 and Cyber Resilience Act checklist
A checklist for operators and manufacturers of industrial and connected products: asset visibility, zones and conduits, remote access, monitoring, patching, recovery, supplier security and the regulatory duties of NIS2 and the Cyber Resilience Act.- 01Eight areas based on IEC 62443 practice, with testable checks.
- 02Incident detection and reporting items for NIS2 and the Cyber Resilience Act.
- 03Supplier and secure development questions for product makers.
- 04Seven questions to put to any vendor or engineering partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Security requirements and risk tiering
Classification of applications by risk and a set of security requirements for each tier, derived from standards and tailored to your technology. - 02
Threat modelling
Structured analysis of data flows, trust boundaries and attack paths at design time, using methods such as STRIDE, with threats turned into requirements and tests. - 03
Secure coding standards and libraries
Language-specific guidance and vetted libraries for authentication, input handling, cryptography and secrets, embedded in templates and frameworks. - 04
Code review and security champions
Review practices focused on security-relevant changes, and a network of trained champions in development teams. - 05
Automated security testing
Static, dynamic and dependency testing in the pipeline, with rules tuned to the stack and findings triaged, deduplicated and routed to owners. - 06
Penetration testing and assessments
Scoped manual testing of high-risk applications and APIs, before release and on a schedule, with retesting of fixes. - 07
API and mobile security
Testing and design review for APIs, mobile apps and integrations, covering authorisation flaws, data exposure and abuse. - 08
Vulnerability management and disclosure
Tracking of findings from all sources to closure with service levels by severity, and a coordinated disclosure process for external reports. - 09
Developer training and metrics
Practical, role-based training and measures such as time to fix, recurring flaw types and coverage, used to improve and not to blame.
Reference architecture.
Standards and interfaces
What we design against.
- OWASP ASVS and Top 10
- The Application Security Verification Standard for requirements and testing, and the Top 10 lists of common web, API and mobile risks.
- NIST SSDF and ISO/IEC 27034
- Frameworks for secure software development practices and application security management.
- OWASP SAMM
- A maturity model for measuring and improving software assurance practice.
- IEC 62443-4-1
- Secure product development lifecycle requirements for industrial automation products.
- Threat modelling methods
- STRIDE, attack trees and data flow diagrams as the basis of design-time analysis.
- Regulatory and customer requirements
- Secure development expectations in financial supervision, the Cyber Resilience Act and customer contracts.
Data model
The core entities.
- Application and risk tier
- Application, owner, data handled, exposure, tier and applicable requirements.
- Threat model
- Diagram, threats, mitigations, owner, review date and resulting requirements.
- Finding
- Source, severity, location, status, owner, due date and closure evidence.
- Test and assessment
- Type, scope, date, tester, results and retest outcome.
- Disclosure report
- Reporter, issue, acknowledgement, triage, fix and communication.
- Training record
- Developer, course, role, date and assessment result.
- Metric
- Measure, team, period and value, such as time to fix or coverage.
When custom development is the right call.
Controls designed in, not added later.
Risk-based effort
The deepest testing and review go to the applications that handle the most sensitive data or face the internet.Fix, do not just find
Findings have owners and deadlines by severity, with escalation, and fixes are verified.Safe testing
Tests run in controlled environments with agreed rules, and test data does not expose real personal data.Protected tooling
Security tools and findings are access-controlled, because they list the weaknesses of your systems.Disclosure channel
A clear route for external reporters, with acknowledgement, triage and fix timelines.
From discovery to a system you run.
- 01
Assessment and risk tiering
We assess current practice, inventory applications by risk and agree the standards and priorities with engineering and security. - 02
Standards, templates and threat modelling
Secure coding standards, templates and a threat modelling approach are defined and tried on a few teams. - 03
Pipeline testing and findings management
Automated testing and central findings management are put in place, and noise is tuned out. - 04
Manual testing and champions
Penetration testing for high-risk applications starts, and security champions are trained in teams. - 05
Measure and mature
Metrics guide improvement, and the programme is reviewed against a maturity model.
Relevant work
Where to see our work.
Common questions.
- What is a secure SDLC?
- A software development life cycle in which security activities are built into each stage: requirements, design, coding, testing, release and maintenance. The aim is to prevent vulnerabilities and to find the remainder early, when they are cheap to fix.
- Is threat modelling worth the time?
- For applications that matter, yes. A short session at design time finds structural problems that testing finds late, if at all. We keep it lightweight and focused on data flows and trust boundaries.
- How do we get developers on board?
- By making the secure way the easy way: templates, libraries and fast, accurate feedback in the pipeline, with practical training and champions inside teams. Security that slows people down is bypassed.
- Do automated tools replace penetration testing?
- No. Tools find known classes of flaw at scale. Skilled testers find logic and authorisation flaws, and chain issues together. Both are needed for high-risk applications.
- Who owns the standards and tooling?
- You do. The standards, the templates, the tooling and the code stay yours.