<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">
Curious about how StrongDM works? 🤔 Learn more here!
Close icon
Search bar icon

Software Development Life Cycle (SDLC) Policy

StrongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

A staggering amount of cybersecurity breaches are caused by software vulnerabilities. From the early worms of the 1980s through the early 2000s - like Blaster, Code Red, and Melissa - to the notable Petya and WannaCry of the past few years, these vulnerabilities are all rooted in software flaws that allowed systems to be exploited.

A Software Development Lifecycle (SDLC) policy helps your company ensure software goes through a testing process, is built as securely as possible, and that all development work is compliant as it relates to any regulatory guidelines and business needs.

Here are some primary topics your software development lifecycle policy and software development methodology should cover:

Create Code

First, figure out where and how it is appropriate for you to start the application development process. Should your project manager create a story in Jira, or does it make more sense to use another project management solution for your development environment? It’s also important to decide how engineers can use the SDLC process most effectively tackle bug fixes, enhancements, new products and UI improvements with the new software they create. Some popular approaches include:

  • Scrum is a framework for managing a process. In scrum software development, there are teams who are self-organizing and don’t officially have a leader. These teams are cross-functional in that everyone works to take a feature all the way from the initial concept to the finished product.
  • Agile development takes scrum teams and supports them with two specific roles. One is a ScrumMaster, who is like a coach for the team and helps members gather security requirements during the design phase and utilize scrum to perform at the highest level. Agile also includes a product owner (PO) role, who represents the business and its customers/users/use cases and provides overall guidance toward building the right product.
  • Sprints are a series of tasks that scrum teams perform in a limited amount of time - usually two weeks and no more than a month long. On each day of a sprint, team members attend a short meeting to share what they’ve worked on that day and the day prior and discuss any foreseen challenges.

Commit Changes

Once developers have the appropriate sandbox for the development phase of code, the next step is giving them a place to control and track changes. Version control systems take a repository of your code and project files and keep a history of all changes, which makes it easy to edit the code - while still understanding it - in the long run. Two popular version control systems include:

  • SVN, also known as Subversion, is the most popular centralized version control system. With this type of system, files and all their historical data are stored on a central server, and developers commit their changes directly to it.
  • Git works in a similar way to SVN, except it uses a local repository in addition to a central repository. To make changes, developers create a copy of the centralized repository on their local machine, make changes, then push those changes back to the centralized repository.

Monitor and Review

Next, you need to log and monitor who has access to your code and who is making changes. You also need a methodology for finding vulnerabilities within your code. Some strategies to accomplish this include:

  • Continuous integration is a set of practices that encourage development teams to make small code changes and then check those changes into repositories at a high frequency. This can lead to higher software quality and better collaboration amongst teams.
  • Continuous delivery picks up where continuous integration ends and automates the delivery of apps to the appropriate infrastructure environments - be they for development, test, or production purposes.
  • Static analysis is a method for finding issues by examining the code without executing it.
  • Dynamic analysis takes the opposite approach of static analysis and looks at code while a program is in operation.

In addition to these monitoring and reviewing approaches, you should also have a way to whitelist pre-approved code changes that have been reviewed by management, as well as quickly identify any non-approved changes that have been pushed to production. See our system changes policy for more information.

Document Thoroughly

Everything we’ve talked about so far needs to be well documented, including the tools/services you use to write code, the methods used to change and publish code, as well as your approach to code review. Be sure to include narratives around your continuous integration and continuous delivery so that the path your code takes from development to staging to production is clear. This verbose documentation helps current, and future team members align with your company’s established way of doing development and also makes an auditor’s job easier.

Set Customer Expectations

Customers will have high expectations of your software - not only from a feature and functionality standpoint but from a security posture as well. Ensure your development strategy includes:

  • Segregation of data between your development, staging, and production data. The development and staging environments, for example, should not have production data in them.
  • Segregation of duties so that unnecessary teams (end users, information technology staff, development and staging testers, etc.) do not have user access to the production environment information systems.
  • Security training for your developers at least once a year. Topics should cover not only software application security concerns but broad security awareness as well, such as phishing, social engineering, appropriate access control, and general network security.
  • A service level agreement (SLA) defines the level of service your customers can expect from you and the remediation you will take if there is a software/service issue. The SLA is not required for SOC 2, but is necessary from a business perspective.

With headline-grabbing software vulnerabilities becoming more and more prevalent, now is the time to tighten up your development practices into a well-written SDLC policy. This particular information security policy will help your development teams standardize on coding tools and practices, as well as get everybody on the same page from a security standpoint. And come the time when you do have an incident, you will be able to demonstrate to your customers that you do indeed take their security seriously - it’s not just lip service.

To learn more on how StrongDM helps companies with SOC 2 compliance, make sure to check out our SOC 2 Compliance Use Case.


About the Author

, Security Engineer / Podcaster, is the president of 7 Minute Security, an information security consultancy in the Minneapolis area. Brian spends most of his days helping companies defend their networks.

Since 2004, Brian has also run the blog/podcast called 7 Minute Security, where he shares what he has learned about information security into short, 7-minute chunks.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

ISO 27001 vs SOC 2
ISO 27001 vs. SOC 2: Understanding the Difference
SOC 2 and ISO 27001 both provide companies with strategic frameworks and standards to measure their security controls and systems against. But what’s the difference between SOC 2 vs. ISO 27001? In this article, we’ll provide an ISO 27001 and SOC 2 comparison, including what they are, what they have in common, which one is right for you, and how you can use these certifications to improve your overall cybersecurity posture.
Answering auditor questions in a SOC 2 review
Answering Auditors’ Questions in a SOC 2 Review
We recently completed our own SOC 2 audit, so we thought we’d review how we dogfooded our own product. We’ll share tips and tricks to make the audit process a little easier, whether you’re wrapping up your own or about to dive into the coming year’s audit. Here are the questions auditors asked us during our own SOC 2 audit and the commands and strongDM tooling we used to gather the evidence they requested.
SOC 2 dashboard
What Would My SOC 2 Dashboard Look Like?
As your organization pursues your SOC 2 certification, organization is critical. ‍You will be busy actively managing dozens of ongoing daily tasks, which can bury you in minutiae. But at the same time, you need to keep your high-level compliance goals in focus in order to successfully move your certification over the finish line.
SOC 2 Audit
Everything You Need to Know About SOC 2 Audits
Whether you’re looking to achieve SOC 2 compliance, or just want to learn more about it, your Googling is bound to lead you to a wealth of articles chock full of buzzwords and acronym soup. ‍In this post, we will provide a guide with definitions, links and resources to gain a solid understanding of everything you need to know about SOC 2 audits.
SOC 2 Policies Guide
A Definitive Guide to SOC 2 Policies
In this post, we will help you get started with a hierarchy to follow, as well as a summary of each individual SOC 2 policy.