Once you complete the code generation phase of any software project, you will have a reasonable level of confidence that the software meets your security and functional requirements. However, any program changes may have unexpected side effects when interacting with other programs. The purpose of formal testing is to evaluate how well your application meets overall performance, functionality, and security goals. Once your development group approves a set of application changes for testing, then the testing group applies any changed programs to its separate environment and carries out test scenarios.

Every goal from the original specification should have at least one corresponding testing scenario. The testing scenario evaluates whether the application satisfies the goal. Every time you identify a vulnerability in your application, include a scenario in your testing package that assesses whether or not a vulnerability exists. Your testing activities can be both manual and automated. Manual code reviews and functionality testing can be very valuable for finding obvious flaws, but automated software analyzers or testing tools allow you to test for far more vulnerabilities in a short amount of time. Numerous companies produce quality application testing and evaluation tools. Here is a list of a few companies that produce products to help you test your applications:

• Microsoft Visual Studio Test Professional—https://visualstudio.microsoft.com/vs/test-professional/

• Synopsis Application Security and Quality Tools—https://www.synopsys.com/software-integrity/security-testing.html

• NDM Technologies Fortify—https://www.ndm.net/sast/hp-fortify

• IBM Security AppScan Source—https://www.ibm.com/security/application-security/appscan

• Eggplant Digital Automation Intelligence Suite—https://eggplant.io/dai

• uTest—http://www.utest.com/

• Inflectra SpiraTest—http://inflectra.com/SpiraTest/Default.aspx#0

An ideal world features at least three environments: development, testing, and production. First, your code must pass all of the required tests in the testing environment. Then, it is ready to release to your production environment. This is the purpose of the implementation phase of the SDLC. Copying programs from your testing environment to the production environment may not seem difficult, but it can cause issues if not handled properly. The best way to handle implementation is to create a copy of a production environment. Then, have your testing group test the implementation process in that environment. Passing an implementation test means you should have no problems when you implement the real code to the real production environment.

One additional common security control for the software development environment is to employ separation of duties. Since software developers can write software that accesses sensitive data, they have the ability to compromise your data’s security. One way to protect your production data from a malicious developer is to not allow any developers to have access to production. Developers write code and can place their software in the testing environment. When testing is complete, another role must have access to move software from testing into production.

So, what can happen from just copying code to production? A lot. Today’s applications tend to be large, integrated systems that depend on many small modules of code. If even one doesn’t work properly, the whole system could encounter problems. This brief list includes some of the problems you might encounter if you implement faulty code to a production environment:

• Inconsistent code and schema changes—Many of today’s applications depend on database management systems to access their data. Database management systems use formal declarations, called schemas, to describe databases. When you change the way a table or column in a database is defined, you change the database’s schema. Programs rely on the database schema to access data and know how to use it. If you implement programs that expect a new schema to a production environment that still has an old schema, your programs may encounter problems. Depending on the language and the database product you use, your programs could either return errors or crash.

• Inconsistent interfaces with other programs—Programs generally work with other programs. To do that, each program has to know how to invoke other programs and what kind of data to exchange with them. If you change a program’s data requirements but neglect to change other programs that expect to exchange data with that first program, they will likely not be able to operate together any longer. Those problems will probably cause errors or program crashes.

• Faulty installation procedure—Due to local environmental differences, your production environment may be slightly different from your testing environment. Any subtle differences, such as folder locations, file permissions, or even defined printers could cause your programs to behave in an unexpected manner.

You may encounter many more potential issues when implementing programs and application changes. It is important to isolate as many issues as possible during your formal testing. However, you won’t identify every problem during testing. Some problems are dependent on the production environment. You won’t see these issues until your application is up and running in production. For this reason, it is necessary to test and evaluate any application changes after implementation.

After installing changes to your application, have your production team execute controlled evaluation scripts that validate the new software functions as prescribed. These tests also ensure that the software doesn’t do what it isn’t supposed to do. Once you are comfortable with the code’s functionality, test its security level. One of the best ways to test for security vulnerabilities in code that is in production is a penetration test. You should be conducting penetration tests periodically anyway; so, this point in the implementation phase is an effective place to do it. Schedule a penetration test soon after you install any application changes. The test will validate that your changes are secure and that no new vulnerabilities exist in your software.