Continuous Integration (CI) is an application development practice that’s becoming more and more popular in large software development organizations. While it boosts productivity and code integrity, it introduces new technical challenges in the security process, magnifying the importance of selecting of the right solution for the task.
Despite CI’s introduction in 2001, IT organizations and companies continued to opt for the conventional sequential development. This also involved the traditional security solutions that were largely implemented towards the end of the production process and at times even after the application was released to the market. This led to spikes in maintenance costs and resource requirements.
But times are changing. The Actuation Consulting research shows that 74% of organizations were using the Continuous Integration and Continuous Delivery (CICD) / Agile methodology in 2013. This trend is continuing to gain steam even today thanks to the numerous productivity benefits, but Continuous Integration security can be challenging due to the various limitations of the traditional solutions.
The problem with traditional application security solutions.
Dynamic Application Security Testing (DAST) has been in high demand in recent years. While definitely helpful in locating numerous vulnerabilities, this methodology has its limitations. Also known as Black-Box Testing, the application has to be past the build stage for it to provide results. This can cause huge delays while developing complex and large projects which in some cases require hundreds of build releases everyday.
Another thing DAST has not been able to excel at is the locating of non-reflective vulnerabilities. One such commonly found application-layer vulnerability is Cross Site Scripting (XSS).
Penetration (Pen) Testing, which involves the active hacking of the application, requires the services of a separate team of testers or a third party vendor. This testing is also performed at the end of the Software Development Life Cycle (SDLC). Not only is this a financially overwhelming solution, it’s not a comprehensive way to fight cybercrime in the long term.
Security Solutions in the Software Life Cycle (SLC).
The financial implications of locating vulnerabilities in the latter stages of the Software Development Cycle (SLC) are well documented. Delays in vulnerability mitigation can prove to be costly, making early detection of vulnerabilities crucial.
The Principles of Continuous Integration Security
While loosely implemented in many organizations, a series of processes need to be implemented in order to achieve complete CICD with comprehensive security implementation in all stages of the Software Life Cycle (SLC). Continuous Integration security starts with proper implementation of the methodology.
The six main steps that need to be taken to ensure optimal Continuous Integration security are:
The stages above typically need to be complete before the traditional security (i.e – DAST) is introduced into the process. But Static Application Security Testing (SAST) solutions, such as Source Code Analysis (SCA), can be integrated from the go. This enables the early detection and mitigation of application code vulnerabilities, enabling smoother development.
This secure process is ideally complimented with smooth Continuous Delivery (CD), which basically means that tested software is always ready to be dispatched and deployed to the users and clients. Benefits of this practice include – improved efficiency and productivity, enhanced product delivery times and better application code integrity.
Creation of a secure SDLC with Source Code Analysis (SCA).
The integration of the static testing solutions into the various development process stages leads to the creation of a secure SDLC. Security requirements are treated as checkpoints and the build is halted as soon as vulnerabilities are located. This ensures the production of robust applications that require minimal post-release maintenance.
Auditors can then simply determine benchmarks as per their specific requirements. For example, build can be automatically be denied when a predefined security threshold has been crossed. In other words, security is integrated into the SDLC just like the Quality Assurance (QA) processes.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.