Software doesn’t write security in by itself; it takes best practices and intent to write good secure software. The industry is starting to agree on this, and the talk by Kelly Shortridge and Dr. Nicole Forsgren at Blackhat 2019 about bringing InfoSec and DevOps together is a great addition to the discussion. In the spirit of sharing more knowledge, here are some tips to help you and your fellow software developers build with more security in mind.

1. Understand Your User

Before writing a single line of code, you must know the “Why” behind your software. What are your user’s needs? How will they use the end-product? Without a clear vision of your ideal user, it’s hard to create a solid framework. Make sure that you have done proper research to answer these questions confidently.

2. Know Your Risks
Security: Start thinking about security before software development has even begun. Continue thinking about security requirements throughout the development and deployment process. Stories, improvements, new features should all include a definition of “Done” that is inclusive of security requirements.

  • Quality: Measure the code quality over time. Benchmark your metrics and provide updates, allowing everyone to see how things are progressing. If you need more information on choosing your metrics, check out O’Reilly’s article on code quality.
  • Prudency: If a system is experiencing issues, how will it affect the user and the bottom line? It is rumored that if a customer signs up for Netflix and their credit card payment system is down, Netflix just gives them “X” number of free days of their service. It’s better to just let the customer stream now and figure out payment later. Netflix realizes that they aren’t losing much money to a few users streaming for free for a few hours.

3. Always Use Coding Best Practices 
These practices include always checking your inputs, having a process in place to prune your code on a regular basis and using TDD and static analysis processes. You should also set up your new features behind feature flags for more control.

Consider using an automated pipeline that does security checking for you, and set it up to run checks all the time(not just specific points in time). Refer to the GSA Information Technology Policy or NIST Cybersecurity standards for more information on methodologies to protect your users.
And of course, make sure engineers get immediate feedback on their code. Be able to answer the following questions:

  • Does it have bugs?
  • Is it written poorly?
  • Is it written with security problems?
  • Does it follow policy?
  • Has it been peer-reviewed?

4. Set Your Engineer Partners up for Success
Train: Whether you are a manager or an engineer, make sure your fellow engineers have an adequate amount of time and resources to learn the skills and tools needed to build the software. This is a marathon, not a sprint, and good practices take consistent work — consider the athletes who are always training. All professions need consistent work to be better.

Strong Communication Tools and Practices: Every engineer should understand the company’s mission and vision. This ensures that they take these values and apply them to their work. When a team knows a company’s purpose, its stakeholders, and how it intends to accomplish its goals, staying on track is that much easier.

Prepare for The Future: Make sure your team knows what may be audited or part of an upcoming compliance check. Knowing compliance requirements, what to expect during an audit and having solid software asset management (SAM) procedures in place can prevent any unsavory surprises.

The key to building more secure software is to consider every angle at the start of your project–including (especially!) security. Ask the right questions, know your team’s capabilities and your user’s needs. The InfoSec landscape is constantly evolving; keeping an eye on its growth, and developing a strong interest for building security into your software is critical to your success.

To get an idea of how your organization is doing, try our LS/IQ DevSecOps score card; it may give you some insight to how mature you are in this process today.

More Resources:

DevSecOps ebook

GSA Policy:

NIST Policy:

Related Blog Posts