Almost all software development projects nowadays perform static analysis as part of their software development lifecycle with a two part goal: 1) catch violations of coding standards; and 2) to catch security violations due to undefined behaviour in embedded programming languages.
Most teams perform this testing out-of-cycle, typically once per day, or once per week. This creates a lot of friction and unnecessary cost between teams.
The testing will reveal a list of findings that will need to be addressed. Someone needs to review this list, assess the findings and then assign these findings to team members for further review and possible fixing.
With coding standards violations, this is straight forward: there is a violation: fix it. The developer will still be unhappy as there is more work to do, after the code had already been delivered.
With a security violation, this turns into a discussion of how dangerous the problem is, how difficult it is to fix it and the priority of the fix. This is all wasted time and creates conflict in the team. Teams do not need this friction and certainly do not have time to waste.
Instead, the approach should be to empower the developer as part of the development work, to clear all these hurdles before the code change is merged.
This presentation will explore the impact of daily/weekly security testing and suggest best practices to bring it closer to the developer to reduce friction and improve team efficiency