Secure Development: Where to Start

Building security into development works when it does not slow the team. If every commit waits ten minutes for a scanner producing nine false positives out of ten, the process will be switched off within two weeks.

This article covers what genuinely protects and what is merely noise.

1. Keeping secrets out of code

The single most important step. An API key, database password or certificate committed to version control stays in the history forever and exists on every developer's machine.

What to do: pre-commit checking and scanning the repository's full history. Where there is a hit, the secret must not only be removed but rotated, because deletion does not erase it from history.

2. Automated dependency scanning

Most of the code is third-party. Automated scanning should be part of the build, with KEV-listed or high-EPSS findings failing the build while the rest merely report. We covered this in our software dependencies article.

3. Static analysis, but narrowly

SAST easily floods a team. Start with a few high-confidence rules (injection, hardcoded secrets, known dangerous functions) and expand only while the false positive rate stays low.

The key: whatever fails the build must be true. After one false block, the team's trust is gone.

4. Code review with a security lens

Not a separate process but existing review extended with a few questions:

• Is there an authorisation check on every resource access?
• Does user input reach a query, command or template?
• Does the error message disclose internal information?
• Does the operation log what is needed, and does it avoid logging secrets?

Four questions covering most real flaws.

5. Runtime secrets management

Secrets belong not in a config file but read from a secrets manager at runtime. Then they are not in the repository, not in the image, and rotatable without code changes.

What not to deploy immediately

Full SAST with every rule. It produces thousands of findings, most irrelevant. The team learns to ignore them, and from then on genuine findings are lost too.

Mandatory security approval for every release. It creates a bottleneck and the team routes around it. A risk-proportionate approach works better: only for larger changes.

DAST on every build. Slow, and it requires a running environment. Weekly or pre-release runs suffice.

Also worthwhile

Threat modelling at design time. An hour discussing who might attack what in a new feature is cheaper than any later fix.

Security baselines for environments. Development, test and production with the same security settings. The most common gap is a test environment holding production data with weaker protection.

Anonymised test data. A copy of the production database in development is one of the most common data protection failures.

What to measure

• How many secrets exist in the repository history
• How many open KEV-listed component vulnerabilities
• Mean time from finding to fix
• False positive rate of build-blocking rules

Our IT security services include reviewing the security of the development process.