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:

  1. 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.

  2. 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?

closed as too broad by 030, Pierre.Vriens, Xiong Chiamiov, Tensibai Jan 3 '18 at 13:23

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Stack Exchange is best suited to questions that can have a definitive answer. For a broad question like this, you are probably better off asking on Reddit, Quora, or similar forums. – Xiong Chiamiov Jan 2 '18 at 21:41
  • That's indeed too broad, there's some companies on this path (testing 'code security' like checkmarx for exemple, without any endorsing on the results, that's just informative) but 'how are you doing X' is unlikely to give satisfying answers and for this case very unlikely to give backed up answers with tangible results. – Tensibai Jan 3 '18 at 13:29

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:

  1. 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.

  2. 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

  • And how do you ensure there's enough unit tests for the whole application and none of the form are vulnerable to code/sql/javascript injection ? (That's everything this question is about) – Tensibai Jan 3 '18 at 13:25
  • Complement after thinking about it: the overall idea is OK, the main problem is ensuring the test coverage is really covering all the app, and that's far from straightforward to be summarized as 'Integrate properly with a CI server' – Tensibai Jan 3 '18 at 14:52
  • I agree that doing it properly has many facets and has to reflect the team’s values. That being said, there is so much support/many frameworks and the payoff so significant that spending time/money on it is well worth it. – Moritz Jan 9 '18 at 18:49
  • I fully agree it worth it :) It just sounds too summarized in your answer to fully answer the question in my personal opinion. – Tensibai Jan 9 '18 at 21:29

This is a little bit of a general question as you said, so my answer is a little general too. We have always made security a part of the development process and we enforce policy to make sure our code is secure. This would include forcing developers to only use languages that can work with your security tools. This needs to be part of the review process. Part of this could be in your automated testing process too.

In my experience many DevOps companies view security as an afterthought because of the fear of slowing down development. This runs counter to the reason companies adopt DevOps in the first place. As you said, security must shift left in the development process. I believe this is in line with DevOps / agile principles. Rather than waiting until a product is complete to think about security. Trying to secure something once it is built or already breached will be far more costly in the long run.

Thanks, John Walsh Conjur

  • I appreciate your reply. As an Application ("software") Security Engineer, this makes me cry, I suppose. As an end user of some of the products, likely, anyway, of the software the teams doing as you describe also breaks my heart and makes me SMH. When will we learn? After how many breaches? Our end user's data and security and privacy are... an after thought. At least we, as a community, admit it. Can we now admit it to our user base as well? Especially when they sue us after we are compromised? – randomNerdboy Dec 29 '17 at 15:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.