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.
