BlogSecurity
Why developers and security engineers should work together
A shared approach turns security findings into practical software improvements.
Security findings are most useful when the people who understand risk and the people who build the software can work through them together. Shared context helps a team understand the problem, choose a suitable fix and verify that the application still does its job.
Give the finding context
A report may describe an unexpected action and its potential impact. Developers can add context about the affected code, design choices, dependencies and normal user behaviour. Security specialists can explain the evidence, test conditions and uncertainty. Neither perspective replaces the other.
For example, a fictional application allows an account setting to be changed by the wrong role. Before changing the code, the team needs to agree which roles should be allowed to make that change and where that rule must be enforced. The application owner may need to clarify the intended policy.
Design and verify together
A narrowly scoped change can enforce the agreed rule, but it should be checked against both the original finding and legitimate use. Include relevant entry points, tests and deployment configuration. Document what was checked and what remains unknown; verification of one scenario does not guarantee that other paths are safe.
Build security discussions into design, review and maintenance instead of leaving every question until the end of a project. NIST’s secure development framework describes practices that can be integrated into an existing development lifecycle.
Make handover useful
Record the reason for the change, its impact on normal behaviour and how the team can run the relevant checks again. Agree who owns remaining work. We regularly explore ways to make security testing and verification more useful to the people maintaining software.
Our vulnerability remediation service brings implementation and security questions together around a defined scope.
