Source code branching strategy and DevSecOps Pipeline at different stages of CI/CD

Source code branch naming conventions

Master branch — All production grade/released source code maintained in the branch. Tags marked for production releases.

Dev branch — Development branch, having source code available for QA testing. Tags marked for business user verification/testing.

Feature branch — Feature branch used by developer(s) for developing features or fixing non-blocker bugs. After successful verification on the Dev environment, the branch should be merged with the Dev branch and this branch should get deleted.

Release branch — Tagged development branch, which can be used for business verification. After successful verification, if any fixes, should be merged with the Master and Dev branch.

Hot-fix branch — Should be forked from tagged master branch, which can be used for fixing critical blocker issues/bugs. After successful verification of fix(es), the branch should be merged with the Master and Dev branch.

Step-1 Pipeline for developer, to verify their feature(s) or fix(es)

Step-2 Pipeline for QA, to run automation suit(s) to fix the current stage of potential release candidate.

Step-3 Pipeline for business users, to verify to be released candidate.

Bigger picture of scm branches and pipelines.

Small intro about the steps/stages mentioned in pipeline

1. Code Scanner

Static analysis tools, also known as code scanners, rapidly look at code and find common errors that lead to security bugs. The tools identify the common problem patterns, alert developers to them and provide suggestions on how to fix the problems. These tools will not take care of underlying design flaws, but they often help developers avoid many security bugs in code long before that code is turned over to testers or is put into production.

Tools

Java — SonarQube

JavaScript — SonarQube, LogRocket

NodeJS — DeepScan, LogRocket

2. Linter/Formatter

Linters and formatters are useful tools that allow you to check, detect errors, and modify your source code, helping you to follow coding patterns with your development team. You can achieve a source code that is legible, readable, less polluted, and easier to maintain by incorporating a linter tool into your project.

Tools

Java — PMD, CheckStyle

JavaScript — ESLint, JSLint, JSHint

NodeJS — ESLint

3. SAST

SAST is a type of white-box security test.

Uncover Common Weakness Enumerations (CWEs) in source code, including custom code, components, and libraries and open source code and components.

Identify both security and quality flaws in code and provide remediation advice.

Help ensure compliance to a wide variety of embedded quality, reliability, and security standards by identifying specific vulnerabilities listed in these standards.

Tools

i) https://www.synopsys.com/glossary/what-is-sast.html

ii) https://docs.gitlab.com/ee/user/application_security/sast/

4. Unit testing & test coverage (Code coverage)

Code coverage is a measure that describes the degree of which the source code of the program has been tested.

Code coverage provides information about whether, and optionally how often certain parts of an application have been executed. It’s commonly used to determine how thoroughly a test suite exercises a particular codebase.

Tools

Java — JUnit, Spring Unit. JoCoCo & Cobertura for code coverage

JavaScript — Jest, Jasmine

NodeJS — Mocha, Chai

5. License Scanning

A typical software project often reuses hundreds of third-party packages. License and origin information is not always easy to find and not normalized.

Tools

i) https://snyk.io/product/open-source-license-compliance/

ii) https://github.com/fossology/fossology

iii) https://github.com/nexB/scancode-toolkit

6. Automation Testing

As the name suggests. Automation testing takes software testing activities and executes them via an automation toolset or framework. In simple words, it is a type of testing in which a tool executes a set of tasks in a defined pattern automatically.

It takes the pressure off manual testers, and allows them to focus on higher-value tasks — exploratory tests, reviewing test results, etc. Essentially, a machine takes over and implements mundane, repetitive, time-confusing tasks such as regression tests. Automation testing is essential to achieving greater test coverage within shorter timelines, as well as greater accuracy of results

What tests should be automated?

Before creating an test automation strategy, let’s have a look at which tests are most feasible for automation:

• Regression Testing: Regression suites are ever-increasing, and require the same variables to be filled numerous times to ensure that new features do not tamper with older functions. This can easily be automated.
• Testing of complex functionalities: Automate all tests requiring complex calculations, something prone to human error.
• Smoke testing: Run automated suites to verify the quality of major functionalities. This saves time by offering a quick analysis of whether a build requires more in-depth testing.
• Data-driven testing: Automate tests to validate functionalities that must be tested repeatedly with numerous data sets.
• Performance testing: Automate tests that monitor software performance under different circumstances. Doing this manually would be extremely painstaking and time-consuming.
• Functional testing: Every time a developer submits a PR, functional testing needs to be executed quickly and provide immediate feedback. This is impossible to achieve without automation, especially as organizations scale up.

Tools

i)https://www.selenium.dev/

ii)https://cucumber.io/

iii)https://rest-assured.io/

7. Performance Testing

While load testing is essential in the production environment, integrating it with CI/CD pipeline can drastically reduce the time and efforts required for performance testing. It is essential to script all possible transactions scripted in the most realistic way and test them for different load scenarios.

Your build may pass all the functional tests, but what about performance? If you ship code without performing Load testing, it might have an adverse effect and bog down your website when high traffic is coming. Deploying a build with CI/CD pipeline is only the half work done in terms of overall performance — Your build also should be able to meet all performance criteria that you have been maintaining since its release. If you are doing it after it is deployed, you miss the most important part: your user experience.

Understanding how your application will behave in the production requires you to perform load testing to get an overall idea about your application’s performance under stress. It is the key to any successful application.

Tools

i)https://jmeter.apache.org/

8. DAST

DAST, sometimes called a web application vulnerability scanner, is a type of black-box security test. It looks for security vulnerabilities by simulating external attacks on an application while the application is running. It attempts to penetrate an application from the outside by checking its exposed interfaces for vulnerabilities and flaws.

The dynamic part of DAST’s name comes from the test being performed in a dynamic environment. Unlike SAST, which scans an application’s code line by line when the application is at rest, DAST testing is executed while the application is running. This is not to say that testing is performed while the application is in production. While DAST can be used in production, testing usually is carried out in a QA environment.

DAST is extremely good at finding externally visible issues and vulnerabilities. This includes a number of security risks from OWASP’s top ten, such as cross-site scripting, injection errors like SQL injection or command injection, path traversal, and insecure server configuration.

One of DAST’s advantages is its ability to identify runtime problems, which is something SAST can’t do in its static state. DAST is excellent at finding server configuration and authentication problems, as well as flaws that are only visible when a known user logs in.

Tools

i)https://www.synopsys.com/glossary/what-is-dast.html

ii)https://www.acunetix.com/product/acunetix360/

9. Smoke Testing

• All the show stoppers in the build will get identified by performing smoke testing.
• Smoke testing is done after the build is released to QA or Business Users. With the help of smoke testing, most of the defects are identified at initial stages of software development.
• With smoke testing, we simplify the detection and correction of major defects.
• By smoke testing, the QA team can find defects to the application functionality that may have surfaced by the new code.
• Smoke testing finds the major severity defects.

This can be sub-set of testcases used in Automation.

10. IAST

Interactive application security testing solutions help organizations identify and manage security risks associated with vulnerabilities discovered in running web applications using dynamic testing (often referred to as runtime testing) techniques. IAST works through software instrumentation, or the use of instruments to monitor an application as it runs and gather information about what it does and how it performs. IAST solutions instrument applications by deploying agents and sensors in running applications and continuously analyzing all application interactions initiated by manual tests, automated tests, or a combination of both to identify vulnerabilities in real time.

Tools

i) https://www.synopsys.com/glossary/what-is-iast.html

ii)https://www.acunetix.com/product/acunetix360/

If you find the article useful, please clap. Thank you.