Why software security fails—and how we build more resilient systems

An exposed password, a vulnerable software component or an API with too much access can turn an ordinary system into a security risk. These problems are harder to fix when security is treated as a final check instead of part of the engineering work.

We build security into the design, code and delivery process. Here are five common mistakes we look for—and how we address them.

“Security isn’t a final gate. It’s a series of choices we make throughout a system’s life.”

— Brian Timmermans

Five security mistakes—and how we address them

1. Waiting until release to think about security

By the time a system is ready to launch, its basic design is already in place. Changing how it handles sensitive information or who can access it may then take more time and effort.

We discuss sensitive data, users, system connections and likely failure points during design. We revisit those decisions as the software changes, and include security checks in development and release work—not only in a final review.

2. Giving people and services more access than they need

An account with broad administrator rights can expose more of a system than a task requires. A private network or VPN does not, by itself, prove that every user or connected service should be trusted.

We verify identity and permissions where systems connect, and give each person or service only the access needed for its work. We also choose protections such as encryption and multi-factor authentication to fit the system and its risks.

3. Overlooking software dependencies

Most applications use software components maintained by other people and organisations. If a component has a known weakness—or changes unexpectedly—it can affect the whole application.

We track dependencies and their risks, lock versions where appropriate, and run regular security scans. We review findings and decide what needs to change; a scan is useful only when its results lead to action.

4. Leaving credentials in code or build systems

Passwords, connection details and API keys can be copied or exposed when they are stored in source code. Build and release systems also need access to important environments, so their credentials and permissions matter.

We keep credentials out of source code, limit who and what can use them, and replace them if exposed. Where the platform allows, we use credentials that expire quickly and have only the permissions a specific task needs. We also restrict which changes can publish software.

5. Assuming a private network is enough

Networks help separate systems, but they do not replace checking each request. If one device or service is compromised, other parts of the system should not automatically be within reach.

We check identity and permissions at system boundaries and limit how far access can reach. Network separation adds another layer where the system and its operating environment call for it.

How we build security into delivery

We choose hosting and identity services to fit each client’s requirements and existing systems. We define infrastructure with Terraform so environments can be reviewed and reproduced. Playwright helps us test browser journeys; SonarQube and Qodo support code quality and review. We use OWASP Dependency-Track to track component risks, Trivy for regular security scans, and OpenTelemetry to connect application signals to monitoring and logging.

Our approach follows ISO/IEC 27001 principles; we are not certified to the standard. EU data residency is the default for client solutions. The specific controls we use depend on the system, the information it handles and the risks involved. Read more on our Security & Trust page.