Imagine you are building a nice apartment for various people to live-in. After the construction is completed and you are delivering the house to people, you realise that the bricks used are weak. That is exactly the situation when your source code is insecure but you deliver the application to customers on time. At every sprint, you are quickly adding more ‘weak bricks’ to the application. Even if the application was originally strong, at every code change done by poorly skilled developer while adding new features, the application becomes weak again. This vicious cycle continues… until we can find a solution to ensure code is created securely.
No matter what defensive security controls are put in place in a production environment, when the application source code itself is weak, it is usually a serious attack surface that is continuously targeted. It becomes even more difficult to protect applications when features are being quickly added into the application for examples as during agile development.
How can you ensure the code is consistently secured at every sprint by every developer without losing the benefits from working in agile?
- Ensure developers have basic security experience and can recognise potential security weaknesses and understand how they can be fixed properly.
- Perform a quick and effective analysis on the source code before pushing the sprint code to the production application.
Our Secure Code Warrior platform addresses the first point by allowing organisations to measure the skillset of each developer and train the developers by doing hands-on challenges in their own language and framework.
|Sample dashboard output from SCW platform|
The second point is often a challenge for “agile” application teams as they face issues on the amount of time available in a sprint to perform analysis themselves or to hire an external company. So, how do we take care of implementing these security tools in every sprint without impacting the delivery date?
The answer is as straightforward as ‘implementing automation’ on using static analysis, so called SAST (Static Application Security Testing) tools. Yes, you read it right. We can automate static analysis on your developer-written source code. Manual effort to run the SAST tools needs to be limited as much as possible. Such implementation of SAST signifies that trained application developers can purely focus on writing secure code and fixing reporting weaknesses, leaving the actual evaluation job to SAST tools. These automatically scan the source-code to uncover hidden security issues to the developers, who can fix it immediately during the sprint. Most static analysis tools like HP Fortify SCA, Checkmarx, IBM AppScan Source, etc. integrate with various industry standard continuous integration (CI) and continuous deployment (CD) tools like Jenkins / Hudson, etc.
The moment you see the above diagram, you might be tricked to think that it may be impractical to implement and use static analysis and dynamic analysis tools in such short sprints, although educating developers before the release begins seems reasonable. So, let’s look at an example. Consider a short sprint of three weeks, which means that new version of application is delivered every 15 days. Before beginning the development of application major version, if we put initial “one-time” effort to integrate industry standard SAST and DAST tools into our CI / CD model of delivery, it could be useful in two ways.
When the developer checks-in the new source code, the CI tool can automatically trigger the static analysis, deploy the code in a test environment and run dynamic analysis, without any manual intervention of an individual. This will provide the developer with a list of security issues found in the source code and the deployed application, when the sprint is about 60% progressed (9th day of the sprint begin). This will enable project team to know the security issues at each sprint.
The project team can than choose to:
● immediately fix the issues (which will add little man-days to the critical path) and delivering a more secure application OR
● Not fix the identified issues but at least the organisation now knows about these issues (e.g. the medium or low risk issues). You will be able to negotiate with your customer on a new delivery date to fix them or to transfer the risk to the customer
This is exactly the significance of effective secure-coding training and integration of static and dynamic analysis tools into CI / CD model. You can keep the benefits of agile development, deliver more secure code or at least know about weaknesses before it becomes too expensive or too late in the process to mitigate them.
Viswanath Chirravuri (Security Architect, Gemalto) and Pieter Danhieux (CEO, Secure Code Warrior)