This is the answer of a question that we receive quite frequently.
Here is a scenario. Let's say that we are working on a project called acme-chat - the next generation web chat software that will change the world. Because this is an important product every time we make a change we want to make sure that it is thoroughly tested. This is why we can ask the developers to produce unit and integration tests. The idea is that before we push the "deploy" button, these tests will run and ensure that the application works before it gets into the hands of our users. Millions of people will be angry if it doesn't.
Now imagine that our software is really important and we want to deliver new features quick. We do not want to wait until the end to run the test suites. What we want to do is to test the product every single time it changes. For example, if Fred, who is working on the emoticon feature, introduces a change we want to make sure that the whole product is tested again. The reason we want to do that is because even tiny change can have a massive impact on the rest of software. Also, providing the developer with early feedback about broken or incompatible features is generally a good thing.
This is called continuous deliver/integration. In other words, we have a defined pipeline that gets a product from the development stage to production. This pipeline is perhaps executed hundreds of times per days as developers are pushing new code.
Now, our pipeline will look like this:
# Continuous Delivery/Integration Pipeline 0. Developer Commits Code 1. Server Builds Code 2. Server Runs Unit Tests 3. Server Runs Quality Assurance Tests 4. Code is Deployed in Staging 5. Server Runs Integration Tests 6. Code is Deployed in Production 7. Users Get New Features
As soon as the developer makes a change this whole process kicks in. That is good but what about security?
Today, security is pretty much artifact that is delivered just at the last stages of the development lifecycle. That is not very cost-effective and it will delay our product from getting it quick to the hands of the customer. It will be very nice if we run some security tests as part of the pipeline to ensure that we are at least covered on some level.
This is Cohesion. If we take the above pipeline and extend it with Cohesion it will look like this:
# Enhanced Continuous Delivery/Integration Pipeline 0. Developer Commit Code 1. Server Builds Code 2. Server Runs Unit Tests 3. Server Runs Quality Assurance Tests 4. Runs Security Tests (Cohesion) 5. Code is Deployed in Staging 6. Server Runs Integration Tests 7. Runs Security Tests (Cohesion) 8. Code is Deployed in Production 9. Users Get New Features
Do you see the difference? We have integrated security as part of the delivery process. Because these tests are executed hundreds of times per day we get some early feedback about the state of the product. If Fred makes a mistake by introducing a Cross-site Scripting vulnerability, we will be able to catch it very early in the build cycle. In other words this vulnerability will never reach our users.
This is a very good software development lifecycle. Unfortunately, not many organisations can do it properly. Even big companies find this task very challenging especially with very complex software. However, even if you are not prepared to deliver software like the method above, we can do something about security.
If for example we give our developers access to professional security tools we can rely that they will use the tools every once in a while to make sure that their code is of a good quality. This is where the Suite comes at play. This single solution can provide all developers access to professional security tools at their disposal. You do not have to install anything and you will be good to go as soon as the solution is purchased.
As you can see the difference is big. A very mature company is likely to have both solutions at their disposal.