Introduction

Overview

In today's interconnected digital landscape, the importance of robust security measures cannot be overstated. Enabling security measures is not just a good practice—it's a necessity in today's digital world. Keeping these in mind, BOS provides different stages dedicated to security in its pipeline templates. These dedicated stages in BOS pipeline templates provides Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) to identify the security gaps.

SAST

SAST is open box testing that scans a software application from the inside out before it is compiled or executed. SAST testing is technology-dependent. So, your SAST tool should support your programming language and development framework to ensure complete testing coverage.

DAST

DAST is useful for detecting misconfiguration in servers or databases that affect web application security during runtime. In contrast to SAST, DAST testing simulates the actions of a malicious actor trying to break into your application from the outside. DAST is technology-independent because it tests the application in runtime from an external user perspective.

Security Stages provided by BOS

1. Code Analysis (SAST)
2. Code Coverage (SAST)
3. DAST

1. Code Analysis

Also know as static code analysis refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within ‘static’ (non-running) source code. It scans code in a project to check for vulnerabilities while validating the code. Based on the report generated, developer can then work and improve their code quality. The code analysis provides valuable insights of the project's codebase. By addressing the identified issues and following the recommendations, we can improve the code quality, maintainability, and security of the application. It also benefits in following ways:

1. Resolve Code Issues: By seeing the report the developer can easily address warnings and errors, variable scope, and other coding standard violations.

2. Reduce Complexity: This also helps the developer refactor functions/methods with high cyclomatic complexity and break down large functions into smaller, more manageable units.

3. Enhance Security: It helps the developer in patching identified vulnerabilities.

You can easily enable or disable the Code Analysis stage by updating the pipeline variables sq_analysis_required value to true. By default the value is false.

2. Code Coverage

Code coverage measures the percentage of code lines executed during testing. When the source code has high test coverage, it means that more parts of its code are checked during testing. This usually means there's a lower chance of hidden software bugs compared to a code with low test coverage. It also benefits in following ways:

1. Improve Test Coverage: It helps the developer increasing the test coverage for critical modules/functions and writing additional test cases to cover edge cases and boundary conditions.

2. Identify Uncovered Code: It provides the analysis of the code sections with low or no coverage.

3. Refactor Complex Functions: It helps in breaking down large, complex functions into smaller, testable units thus improving the modularity and readability of the code to facilitate testing.

You can easily enable or disable the Code Coverage stage by updating the pipeline variables sq_coverage_required value to true. By default the value is false.

These stages utilize the SonarQube tool to generate reports, aiding in the improvement of clean code. This results in software that is secure, reliable, and maintainable. To configure SonarQube click here.

3. DAST

It involves testing an application in its running state to identify vulnerabilities and security weaknesses.This stage provides artifacts. It identifies vulnerabilities that pose potential risks to the application's security. By addressing the identified vulnerabilities, implementing recommended security measures, and conducting regular security assessments, we can enhance the application's resilience against cyber threats. It also benefits in following ways:

1. Patch High Severity Vulnerabilities: This helps in immediately addressing and patching critical vulnerabilities and implementing security updates and fixes as recommended by the report.

2. Mitigate Medium Severity Vulnerabilities: It helps in developing and implementing strategies to mitigate medium severity vulnerabilities and applying security controls such as input validation and output encoding.

3. Address Low Severity Vulnerabilities: It also provides the list of low severity vulnerabilities which should be acted upon to prevent potential exploitation.

Just like SAST stage, you can enable or disable DAST stage by updating the pipeline variable zap_dast_required. By default the value is false. This stage utilize the ZAP tool to generate reports which helps in finding the security gaps.

Input Variables for SAST

Below are the input variables which will be used in the SAST stages

Input Variable Name	Description	Default Values	Type	Supported Values
sq_auth_token	The authentication token used to access SonarQube which will be configured here	{{SonarQube.SonarQube1.AuthToken}}	string
sq_url	The URL of the SonarQube server which will be configured here	{{SonarQube.SonarQube1.Url}}	string
sq_coverage_required	A flag that determines whether code coverage metrics are required	true	bool	true, false
sq_analysis_required	Enabling this option ensures that project code is analysed by SonarQube	true	bool	true, false
sq_project_key	The unique project key or identifier for the SonarQube project	myappkey	string

Input Variables for DAST

Below is the input variables which will be used in the DAST stage

Input Variable Name	Description	Default Values	Type	Supported Values
zap_dast_required	A flag that determines whether DAST metric is required	true	bool	true, false
openapi_url	For API endpoints swagger URL is required. For example swagger/v1/swagger.json		string

✖