DevSecOps Best Practices Checklist

This piece features an actionable checklist to ensure your DevSecOps program succeeds by following best practices to help avoid pitfalls along the way. 

DevSecOps Best Practices 

• Work towards the efficiency of the entire system, not just your part(s)
  • This may mean periodic review of your (security) portions of the pipeline to ensure maximum effectiveness, speed and accuracy. It may also mean yanking out a tool entirely and replacing it or redeploying it.
  • If you can save hundreds of hours of development time, it is a worthy investment.
• Provide automation of testing outside of the pipeline
  • For example, overnight or other out-of-band runs for long and/or inaccurate tests.
  • This will help avoid delaying others’ work.
• Verify results for tools that tend to provide a lot of false positives
  • Do this before handing them to the development team.
  • For example, first-generation SAST products.
• Provide security feedback as soon as possible
  • This may mean running tests when developers check their code into the repo or other opportunities before the pipeline.
  • Provide feedback as quickly and often as possible.
• Work hard to ensure feedback you provide is consistently accurate and gets to the correct people
  • Inaccurate feedback or feedback that doesn’t get to the right people is wasted effort on both sides.
• Create different SLAs for legacy security bugs versus newly found issues
  • Sometimes this is called “grandfathering.”
  • Legacy bugs must still be fixed, but generally, the SLA is more generous than for newly created bugs.
• Whenever possible, assist DevOp teams in meeting their SLAs
  • This may mean helping them understand the tools or findings better, providing management support when they ask for more resources to fix bugs, or even (occasionally) fixing bugs yourself.
• Automate the findings that you feel confident about being imported into the Backlog/Bug tracker
  • Also automate your vulnerability management by exporting this into whatever tool you use for this purpose (assuming you do not use the bug tracker for vulnerability management as well).
• Test tools in alerting-only mode until you are certain it’s no longer reporting false positives
  • It is very important to avoid breaking builds over inaccurate results.
• Whenever possible share lessons learned 
  • Any lesson—not just security-focused ones.
• If possible, break your work into sprints or schedule your work alongside the Dev team’s release cycles
• Celebrate success every chance you get
  • Security often only gives negative feedback; using every chance you can to be positive will not only build trust but make your office a nicer place to work.
  • Create a security-positive culture, in addition to a DevOps culture.
• Require testing from at least three angles
  • The three angles are dynamic analysis, static analysis and analysis of dependencies/third-party code.
• Ensure the entire SDLC includes security activities, not just the continuous integration/ continuous delivery (CI/CD) lifecycle
  • This could mean adding security project requirements, threat modeling, design review, custom app alerts and monitoring, software-focused security incident tabletop exercises, etc.
• Provide regular training for all teams on how to do their jobs securely
  • Include annual secure coding training. 
• Put the power into the hands of the DevOps teams
  • Provide tools with integrated development environment plug-ins, licenses and training so they can perform as much testing as possible before the pipeline begins.

READ:  Secure Coding Basics for Developers 

DevSecOps Issues to Avoid 

• Breaking builds due to false positives
• Tools in the pipeline that run for extended periods of time
• Uneducated staff assigned duties before training and without on-the-job experience
• Allowing security bugs to go into the backlog and be ignored for long periods of time
  • The backlog should not be a place where vulnerabilities are filed so they can be ignored.
• Creating SLAs for security issues that are realistic but also get stricter over time
• Using the CI/CD to create artificial gates
  • We break builds if forced in order to avoid a security disaster, not to slow other teams down to our speed.
• Demanding all legacy bugs be fixed before releasing to production once the new pipeline is implemented
  • This approach will not win you any friends and is generally not realistic.
  • It’s not an emergency if it’s already in prod and has been for years.
• Using security tooling that does not import the findings into the bug tracker or systems the developers use to track their work
  • They cannot be expected to log into one or more additional systems in order to see the security bugs they are expected to fix.
  • Make it as convenient as possible for best results.
• Having insecure SDLC; there should be more security activities than just tests in the CI/CD
• No positive reinforcement
  • If the security team only appears to deliver bad news, people won’t be happy to see you.
  • Whenever possible, recognize and reward good behavior.
• Overly permissive privileges on the CI/CD
  • Some employees will disable tests to “get to prod.” Lock this down.
• Hiding security testing results/bugs
  • It’s difficult for other teams to learn if we hide all of our mistakes.
  • We can turn some of these into lessons, so we never make those mistakes again.
    

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.