Software Security Testing in a DevSecOps Pipeline

This is a somewhat general question by design, intended for discussion of process. At my current (and all previous) companies we had issues with releasing insecure software into production. This cut across the divide from mobile, web, API's, internal, external, critical and non-critical applications and systems. If we built it, it had/has security issues... just like your company. In addition, we lack support stack (qualified application security engineers who "knew code" and not just glorified pen testers who didn't know JavaScript from Java) so we could not scale services as needed. Hence automated software security scanning in the SDLC and now in the DevSecOps CI/CD pipelines. We face the issues of:

-
Service Level Agreements - our dev teams want/need results in minimal time, we all know that's not happening with either DAST or SAST tools without heavy configuration.

-
Allowing teams to choose their own language and not even having static code support... leaving us with DAST if applicable or, ugh, pen tests, which in my view are essentially useless.

We need to shift software security "left" - from point of inception, not wait until code is in production and hope we detect the vulnerabilities - I am sure someone will find them, most likely not the pen test team we are paying huge money for, however.

Automation of static and dynamic tools, properly configured, driven off a threat model seem to be our only options to get ahead of the game. We all know "developer education" is a lost cause.

How is your company/team solving this, assuming they even are or recognize it as a problem to address?

I agree that relying on "developer education" is quite futile, at least when it's the sole course of action. Combine this, however, with automation and you can achieve far greater impact. Both sides, DAST and SAST can be covered with:

-
Unit test authentication: Make sure that you have unit tests that check registration, login, password reset and that it is integrated with your development process (continuous integration). Implement processes that automatically block changes to your code when they fail.

-
Testing against known vulnerabilities: These are automated DAST tests that test your application from outside. Programs that handle this task include BDD and mittn which is inspired by GAUNTLT.

Integrate everything properly with a CI server (Jenkins, Gitlab, Travis) and stop having to rely on your programmers' "best effort security"

Note: my opinion of proper CI integration, from a language/platform agnostic view, covers the following

Tests/examples:
- unit tests that cover at minimum 80%, better 90%
- integration tests that ensure the modules work with one another
- example programs that show how a user should use the API

Build automation:
- Automatically build every pushed commit
- Build library, test and example code
- Build for each platform/configuration
- Run the tests

Merge/pull requests:
- Block merges into master branch if any thing fails
- Require code review of at least one other colleague

Code analysis:
- Run nightly static code analysis (style, anti-conventions, dangerous constructs)
- Run nightly dynamic code analysis (memory leaks, race conditions, known security flaws)

Publish results:
- Publish graphs/trends of test/analysis history
- Talk about changes/targets in weekly meetings
- Act on problem areas with sprints/work packages

StackExchange DevOps Q#2983, answer score: 2