4 Best Practices for Secure Software Development and Testing

The recent ransomware attacks on the Colonial Pipeline, which plunged the eastern US into a gas shortage, have shone a glaring spotlight on the importance of secure software development. 

Cybersecurity experts assure us that large energy concerns are far from the only target—individuals, small businesses, and local governments can easily become the target of ransomware attacks and other cybersecurity threats. In 2020 the global cost of cybercrime tipped the scales at over $1 trillion.

The need for secure software development life cycles has never been more stark. If a custom software development project is in your near or immediate future, you need to start thinking about the security of the development process now. Here are four best practices for secure software development and testing. 

Secure Software Development Best Practice #1: Document Your Processes

At the heart of secure software development sits a fundamental rule—document, document, document. Document everything, and then document some more. If the software development lifecycle doesn’t produce a raft of documentation, you know something is amiss and the security of the development cycle is suspect.

Every secure software development life cycle (SDLC) includes rigorous requirements for documentation at every level. If vulnerabilities are discovered, you have to be able to retrace the steps of the development life cycle to identify the source of the vulnerability and correct it. Documentation is also essential for the accountability and traceability requirements that accompany regulatory compliance.

Documentation is necessary at every step of the software development life cycle, including:

1. The Planning Stage. This includes documentation of the definition of the product—its intended appearance and function. Planning documentation includes both high-level and low-level design and requirement specs.

2. The Quality Assurance Stage. This includes documentation of testing standards, test types, test flow, definition of testing subjects, and recording of QA testing results. 

3. User Documentation. This includes documentation of instructions for installation, usage, and maintenance, including end-user guides, installation guides, and system documentation,  

4. Release Documentation. This includes final reports subsequent to the release date.

One of the advantages of the agile development approach is that it lends itself to documentation. It is collaborative and iterative by nature, with libraries of documentation accumulated as a matter of course. Compare that to the more sequential and antiquated waterfall approach to product development. This linear process requires much more documentation upfront, with fewer opportunities for documentation later on.

Process documentation differs from product documentation. It records all the activities that take place around the product—in other words, the process that brings the product into reality based on the initial product documentation. Examples of process documentation necessary for secure software development include:

• Estimates and Schedules. Documentation of expected costs and delivery times. 

• Metrics and Reports. Daily, weekly, and monthly documentation of the resources expended in the development life cycle.  

• Working Papers. A record of engineers’ input during the development life cycle, including sketches, code, and troubleshooting notes.

• Standards. Documentation of all UX and coding standards that the development team adheres to.

While process documentation is time-specific and may become obsolete, it provides crucial transparency in the software development process, while also making similar processes easier to duplicate. 

Secure Software Development Best Practice #2: Make Time for Training

Much of the responsibility for developing secure software lies in the hands of the developers themselves, but much of the responsibility for maintaining the security of the application will fall to the IT team that takes the hand-off once the software solution is delivered.

Organizations must make time to offer that team secure software training specific to the new software solution—to do it early, and repeat it often. Otherwise, all the effort they put into developing a secure software solution could be for naught. The organization could face increased costs hiring security experts to patch vulnerabilities or potentially become the victim of a disastrous breach. 

Secure development training includes four basic phases:

1. Establish a Baseline. Every training program needs a “canon”—a common frame of reference that everyone can agree on. One great resource is the Open Web Applications Security Project (OWASP), which has been compiling an encyclopedic record of known security vulnerabilities and attack vectors on various kinds of software since 2003.  

2. Identify the Most Important information. Narrow down your baseline knowledge to the most relevant portions of the canon—information that applies to the specific secure software solution you will train on. Start building training modules around that identified information. 

3. Conduct Theoretical Training. This is the “classroom” portion of the training. It can include lectures, presentations, even group work, grounding trainees in the basics of the relevant information. 

4. Conduct Hands-On Training. Once the classroom portion of learning is done, it’s time to get practical. Trainees should conduct hands-on simulations of the secure software best practices they learned during theoretical training. This is the bridge between knowing and doing. 

The training should include an evaluation phase and confirmation that the trainee has left the session with a working knowledge of how to maintain the security of the software solution. Additionally, stakeholders should plan on retraining and supplementary training, especially after a major update. 

Secure Software Development Best Practice #3: Test and Retest

You can’t just take secure software development on faith. The finished application must be tested. Then re-tested. Then tested again.

Testing formerly involves manual review of every line of code by security experts, but this time-consuming approach has largely been replaced (or at least supplemented) by various automated software tools designed to test the code.

Many different types of software security testing tools exist, including:

• Static Application Security Testing (SAST). SAST tools perform static code analysis—an automated review of the software code in its uncompiled, non-running state. SAST tools usually return a long list of potential vulnerabilities, which must then be manually checked to confirm if they are actually vulnerabilities. But it beats having to review every line of code manually.

• Dynamic Application Security Testing (DAST). DAST tools test the application in its running state. They ping the software with inputs meant to simulate a possible attack or attempt to cause a program failure. 

• Interactive Application Security Testing (IAST). IAST tools are an advanced form of application scanner that tests the application in its running state. It produces test cases of simulated attacks and “learns” about its vulnerabilities based on the application’s performance. They tend to produce fewer false positives than DAST tools.

• Mobile Application Security Testing (MAST). MAST tools perform static, dynamic, and forensic code analysis to identify issues specific to mobile applications. 

• Software Composition Analysis (SCA). SCA tools trace components of the application back to the source libraries, including open source libraries, in search of vulnerabilities specific to that source library.

• Database Security Scanning. A database might not be included in an application, but developers may rely on external databases that could introduce vulnerabilities. Database security scanners look for database-specific vulnerabilities like weak passwords, patches, access control list, and configuration errors.

• Correlation Tools. Many of the above tools produce false positives. Correlation tools import the findings of the other tools to compare notes between the findings.

• Test-Coverage Analyzers. Test-coverage analyzers keep track of how much of your code has been tested so you can chart the progress of your testing efforts.

Developers often hire third-party data security specialists to perform a “penetration test”—a focused attempt to breach the software. Penetration testers are sometimes called “ethical hackers,” since they use the tools and techniques of hackers to expose an application’s weaknesses. Once the penetration test is done, the ethical hacker presents a list of vulnerabilities discovered during the test. 

Secure Software Development Best Practice #4: Have a Post-Launch Security Plan

Your launch date is just the beginning. Once your software solution is in the hands of users, the real work begins. In the real world, it becomes a target of hackers. Your secure software development life cycle has produced the most secure software solution possible out the gate, but no software solution is completely invulnerable, no matter how many precautions you take.

It is important, therefore, to have a solid post-launch security plan in place at the time of launch. Components of a post-launch security plan include:

• Assign an Ongoing Security Team. Decide who will be accountable for the ongoing security of your software solution. This could be formed from within your IT team, or it could be a third-party provider. But the buck must stop with someone for the purposes of traceability and accountability.

• Schedule Further Testing and Validation. The testing and documentation really never stop. You should run regular scans of your code and possibly even order regular penetration tests to proactively find new vulnerabilities in the code that may result from patches, updates, and new features. 

• Continue Training. Another ongoing part of secure software development is training. Don’t just stop at the pre-launch training. Have ongoing supplemental and revisit training, as well as training sessions for new hires, to make sure that everyone is up to speed on the best ongoing security practices. 

Conclusion

The threat of cybercrime has never been higher, but the tools to ward it off continue to advance in step. By committing to secure software development best practices—documentation, training, testing, and post-launch strategy—software owners can minimize their risk, offer users peace of mind, and prosper in a digital future.