Security quality gates

Awareness gained from data, such as audit or scan reports in 42Crunch API Security Platform, is good but it gets even better when you can act on that data. Security quality gates (SQGs) let security team define the minimum criteria that developers must ensure their APIs pass before they can move to the next stage in their development lifecycle. This way you can be assured that the APIs executed in your API infrastructure meet the security level that you want.

How security quality gates work

Organization administrators can create SQGs and set the baseline for specific quality criteria that APIs in their organization must reach. As part of performing an action like auditing the API definition, APIs must also meet the criteria of the SQG.

Each organization automatically gets a default audit and scan SQGs out of the box, so that you have overall quality indicators at your disposal right from the start. You cannot delete the default SQGs, but you can edit them as needed. For the free community organization, 42Crunch provides default SQGs with basic settings.

The screenshot shows the default security quality gate in its default configuration.

Tags are the mechanism for applying additional SQGs to your APIs. The default SQGs are automatically applied to all APIs in your organization, no tagging required. For other SQGs, you define the category:tag pair that goes with it. Then, to apply the SQG to your APIs, you tag each API with the tag for the SQG you want. For example, you might want to apply different SQGs depending on the execution environment (development, pre-production, production), data sensitivity, or regulatory context (financial, healthcare) of the API. Each category:tag pair can apply only a single SQG, but you can add more than one tag to your API to apply multiple SQGs to it. All applied SQGs are executed independently of one another.

We recommend adding a dedicated category for SQGs, so that it is easy to find the related tags. If you want, you can also restrict that category so that users can only apply a single tag from it and thus single SQG to any one API.

Approval report

When you audit or scan an API that has one or more SQGs applied to it, 42Crunch Platform compares the results to the criteria defined in each of the SQGs separately. If the criteria are met in an SQG, the API passes it, and your CI/CD pipeline progress can continue. If the criteria of an SQG are not met, the API fails the gate.

In both cases, you get an approval report that shows which SQGs the API passed and which it did not. Each failed SQG lists the criteria that were not met.

If the API passes all SQGs, the report is an assurance on the security of the API. However, when an API fails a SQG, the approval report provides the starting point for aligning the API with the expectations of your organization. Aiming to address the failures from the approval report first could help avoid unnecessary work when fixing things.

The SQGs are grouped to approval report by report type, so you can see audit SQGs in one approval report, and scan SQGs in another.

Security quality gates and CI/CD integration

SQGs are most powerful when used in your CI/CD pipeline, acting as gate keepers and stopping APIs that exceed your risk appetite entering your code base if the API does not meet the set criteria.

You must integrate API Security Audit to your CI/CD pipeline before SQGs can affect your builds. CI/CD integration for API Conformance Scan is coming, but currently scan SQGs can only be enforced in 42Crunch Platform, not on your CI/CD.

You can integrate features in 42Crunch Platform with your CI/CD solution through custom plugins that adds a build step to your pipeline to, for example, to automate Security Audit from a simple Git push to your project repository. Once you have set up the integration plugin for your CI/CD pipeline, on each build the plugin automatically checks the status of all SQGs applied to the APIs it found in the repository. If any of the SQGs fails, the build automatically fails too.

For more details, see CI/CD integrations.

Security quality gates and customization rules

SQGs and customization rules are not one and the same: while customization rules affect what happens within 42Crunch Platform, SQGs take effect in your CI/CD pipeline.

However, sometimes SQGs overlap with customization rules. For example, you could list a particular issue or test ID as forbidden in your SQG, but have a customization rule that excluded that particular ID. In this case, the SQG would be ineffective, because the case that the SQG safeguards against would not be checked for at all and its presence could go undetected.

We recommend that you do not apply both SQGs and customization rules to the same API, or if you do, you carefully check that they do not conflict.

Security quality gates in API Security Audit

Creating SQGs for Security Audit helps you ensure that the quality and security of all API definitions that are pushed to your code base are what your want them to be.

You can define several criteria that the OpenAPI definition must reach in the audit, such as:

  • Reject OpenAPI definitions that have structural or semantic issues so that they no longer can be considered valid OpenAPI definitions by failing the SQG outright.
  • Set minimum scores that OpenAPI definitions much reach.
  • Define the allowed severity levels for found issues in each category and subsection. If issues of that severity or higher are found in the audit, the API fails the SQG.
  • List issues (by issue IDs) that are never accepted in your APIs. If any if the listed issues is found when auditing an API, the API fails the SQG.

Security quality gates in API Conformance Scan

Creating SQGs for Conformance Scan helps you ensure that all APIs are implemented in a way that meets your requirements and risk appetite.

You can define several criteria that the API implementation must reach in the scan, such as:

  • Reject API implementations that could not be scanned fully, for example, because of failing happy path requests or other errors encountered during the scan.
  • List which vulnerabilities from OWASP API Security Top 10 are blockers for your API implementations.
  • Define the allowed severity levels for problems that the scan finds. If problems of that severity or higher are found in the scan, the API fails the SQG.
  • What percentage of the operations must return a HTTP status code that Conformance Scan expected for the test in question.
  • List problems (by test IDs) that are never accepted in your API implementations. If any if the listed tests finds problems when scanning an API, the API fails the SQG.