DevSecOps Best Practices Checklist

To ensure your DevSecOps program is a success, there are certain best practices to follow, and pitfalls to avoid, that will
help you succeed in the long run.

Best Practices
 WORK TOWARD 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 DEVOPS 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 IS NO LONGER REPORTING
FALSE POSITIVES

 It is very important to avoid breaking builds over inaccurate results.

© 2023 IANS Research. All rights reserved. 1
 DevSecOps Best Practices Checklist

 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
DEVELOPMENT 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.

Pitfalls 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 MORE STRICT 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.

© 2023 IANS Research. All rights reserved. 2

 DevSecOps Best Practices Checklist

 It’s not an emergency if it’s already in prod and has been for years.

 USING SECURITY TOOLING THAT DOES NOT EXPORT THE FINDINGS INTO THE BUG TRACKER OR
SYSTEM 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.

© 2023 IANS Research. All rights reserved. 3