Secure Software Development Life Cycle: Beginners Guide

In this post, we will be trying to answer following questions to integrate security into our software development life cycle (SDLC) ;

1. Which projects should be scanned more frequently?

2. When should scans be triggered within the SDLC of each project ?

Immediate answer is, software architecture is the first thing to consider relating to the former question whereas branches provide a solution for the later.

Each project has a unique architecture that addresses certain needs trying to be met by the software. That is why there might be a lower margin of error in some projects (i.e those that store sensitive information or credentials) and more frequent scanning might be necessary whereas others can be scanned at a much lower frequency.

Even though projects are not equal in their security perception, each branch within a project also has different risk perception in terms of software security. So let’s quickly look at how these two factors can be useful to decide on scan frequency.

When should your projects be scanned ? Should they be triggered on a calendar basis (every Wednesday, every Friday etc.) or by web hooks when certain actions (pull request, merge etc.) take place in your software development platform.

This is mostly an optimization problem as we have extremely scarce resources to scan our projects from a human resource perspective as well as scanner licence and time perspective.

Architectural differences

Scan duration is an important factor in the frequency of scans as nobody would be willing to halt the development pipeline for hours before the scan is finished. Micro-services enable a higher scan frequency as scans are likely to take much shorter amount of time in such an architecture.

If it is a software built for internal use, you can comfortably extend the period between scans to create more scanner bandwidth for the customer-facing external projects.

If it is a software whose source code rarely changes, it would be a wise move to use web hooks to initiate a scan every time there has been a change in the source code. This would prevent scheduling calendar based scans and eating up scanner bandwidth needlessly when nothing has changed in your source code since the last scan.

If it is a software that faces constant pull requests and merges, starting a scan each time a web hook is triggered can overload your scanners. Instead, you can use scheduled web hooks that check at a specific time of each day to verify if the web hook has been triggered one or more times in the last 24 hours and decide accordingly whether to start a scan or not.

If the project is developed by a third party, the best practice would be to impose mandatory source code analysis on the contractor company and receive results on a periodical basis. For cases when this is not an option, integrating security tests into the CD pipeline can ensure that whatever software is shipped by your contractor will automatically be scanned by your scanners.

Branch security

As the timing of different scan technologies is inherently decided by the nature of scanner type, SAST and SCA scans are better suited to take place in the development and testing branches whereas DAST scans typically are run on testing and production branches.

SAST and SCA technologies scan source code and aims earlier stages of SDLC whereas DAST requires a production-like environment to function.

Development branches

These are the branches where the actual work happens. Typically, software developers branch off to work on features and then features are merged to the branch. SAST and SCA are the only options we have at this point as we do not have a production-like environment to run DAST yet.

Depending on the average duration of a full scan, it is possible to opt for incremental or full scans. Full scans are definitely more preferable from a security perspective. However, in large projects, scan duration can go up to several hours and in cases like this incremental scans come to our rescue. Even though this might vary between companies, we adopt incremental scans when full scans take longer than 45 min – 1 hour.

Incremental scans for each merge request coming in to the development branch will ensure new features are scanned prior to being merged. Incremental scans take a shorter amount of time as only the code in the last commit is scanned. Even though incremental speed up the scanning process, please bear in mind that their scope is limited and vulnerabilities that are not identified in incremental scans can be identified in full coverage scans later on due to dependencies within the source code.

SCA scans identify known vulnerabilities in the open source components used in your applications. They have gained popularity as software developers heavily rely on third party libraries and today, on average 60-70% percent of the source code in applications consist of these third party components. Without a SCA scanner in place, an important piece in your application security layer would be missing.

Testing and production branches

In testing branches, DAST scans are run along with full coverage SAST scans, user acceptance tests and functional tests. Vulnerabilities discovered at this stage need to be checked against those discovered by SAST tools to see if there has been any leaks carried forward to the testing branch. Any kind of vulnerability that has been mutually pointed by SAST and DAST is a usual suspect and a good reference point on where to start working on vulnerabilities.

If the project is huge and a full coverage SAST scan takes too long, there are two handy options relating to when to run a full scan on the project. First is to run asynchronous security tests in the development branch at midnight or lunch break to make use of the idle times without hampering the flow of DevOps pipeline.

Second option is to run full-coverage scans on a calendar basis with a regular frequency in the master branch of the project. Weekends can be ideal to schedule full scans on the master branches of large projects to get back onto the results on Monday morning. This would also allow hot fixes that branch off the master branch to be scanned at regular intervals. This way vulnerabilities identified in the master branch can also be added to your development sprint plan.

Relating to the scanning frequency of branches, testing and master branch can be scanned at a much lower frequency than development branch as the natural flow mandates software to hit development branch first and testing and master branches later.

In our next post, we will be looking into how branch structure can also influence decisions on which vulnerabilities to assign to your developers on your defect trackers and on what security conditions you want to break the build process.