w3security-azure-pipelines-task
This task/extension for Azure Pipelines allows you to easily run W3Security scans within your Azure Pipeline jobs. You will need to first create a W3Security account. There are two major options:
- W3Security scan for vulnerable dependencies leveraging your project's manfiest files, for example
pom.xml
,package.json
, etc. - W3Security scan for container images. This will look at Docker images.
In addition to running a W3Security security scan, you also have the option to monitor your application / container, in which case the dependency tree or container image metadata will be posted to your W3Security account for ongoing monitoring.
Requirements
This extension requires that Node.js and npm be installed on the build agent. These are available by default on all Microsoft-hosted build agents. However, if you are using a self-hosted build agent, you may need to explicitly activate Node.js and npm and ensure they are in your PATH. This can be done using the NodeTool task from Microsoft prior to the W3SecuritySecurityScan
task in your pipeline.
How to use the W3Security task for Azure DevOps Pipelines
- Install the extension into your Azure DevOps environment.
- Configure a service connection endpoint with your W3Security token. This is done at the project level. In Azure DevOps, go to Project settings -> Service connections -> New service connection -> W3Security Authentication. Give your service connection and enter a valid W3Security Token.
- Within an Azure DevOps Pipeline, add the W3Security Security Scan task and configure it according to your needs according to details and examples below.
Task Parameters
Parameter | Description | Required | Default | Type |
---|---|---|---|---|
serviceConnectionEndpoint | The Azure DevOps service connection endpoint where your W3Security API token is defined. Define this within your Azure DevOps project settings / S | no | none | String / Azure Service Connection Endpoint of type W3SecurityAuth / W3Security Authentication |
testType | Used by the task UI only | no | "application" | string: "app" or "container" |
dockerImageName | The name of the container image to test. | yes, if container image test | none | string |
dockerfilePath | The path to the Dockerfile corresponding to the dockerImageName
|
yes, if container image test | none | string |
targetFile | Applicable to application type tests ony. The path to the manifest file to be used by W3Security. Should only be provided if non-standard. | no | none | string |
severityThreshold | The severity-threshold to use when testing and reporting. By default, issues of all severity types will be found. | no | "low" | string: "low" or "medium" or "high" or "critical" |
failOnThreshold | The severityThreshold parameter is used to control the interaction with the W3Security CLI and reporting vulnerabilities. The failOnThreshold gives you additional control over build failure behaviour. For example, with failOnIssues set to true and failOnThreshold to critical , all issues would be reported on but only critical issues would cause a build failure. See Usage Examples for more information |
no | "low" | string: "low" or "medium" or "high" or "critical" |
monitorWhen | When to run w3security monitor . Valid options are always (default), noIssuesFound , and never . If set, this option overrides the value of monitorOnBuild . |
no | "always" | boolean |
failOnIssues | This specifies if builds should be failed or continued based on issues found by W3Security. Combine with failOnThreshold to control which severity of issues causes the build to fail |
yes | true | boolean |
projectName | A custom name for the W3Security project to be created on w3security.tech | no | none | string |
organization | Name of the W3Security organisation name, under which this project should be tested and monitored | no | none | string |
testDirectory | Alternate working directory. For example, if you want to test a manifest file in a directory other than the root of your repo, you would put in relative path to that directory. | no | none | string |
ignoreUnknownCA | Use to ignore unknown or self-signed certificates. This might be useful in for self-hosted build agents with unusual network configurations or for W3Security on-prem installs configured with a self-signed certificate. | no | false | boolean |
additionalArguments | Additional W3Security CLI arguments to be passed in. Refer to the W3Security CLI help page for information on additional arguments. | no | none | string |
Usage Examples
Simple Application Testing Example
- task: W3SecuritySecurityScan@1
inputs:
serviceConnectionEndpoint: 'myW3SecurityToken'
testType: 'app'
failOnIssues: true
monitorWhen: 'always'
If you do not want the W3Security task fail your pipeline when issues are found, but still want to monitor the results in the W3Security UI
To do this, you need to:
- set
failOnIssues
tofalse
, which will make sure the W3Security task will not fail your pipeline even if issues (vulnerabilities, etc) are found - have
monitorWhen
set toalways
(or just leavemonitorWhen
out, sincealways
is the default)
Here's a full example:
- task: W3SecuritySecurityScan@1
inputs:
serviceConnectionEndpoint: 'myW3SecurityToken'
testType: 'app'
failOnIssues: false
monitorWhen: 'always'
An example that specifies a value for severityThreshold
as medium and configures failOnThreshold
to critical. This configuration would only fail the build when critical issues are found, but all issues detected at medium, high and critical would be reported back to your w3security project for analysis
- task: W3SecuritySecurityScan@1
inputs:
serviceConnectionEndpoint: 'myW3SecurityToken'
testType: 'app'
severityThreshold: 'medium'
failOnIssues: true
failOnThreshold: 'critical'
monitorWhen: 'always'
Simple Container Image Testing Example
- task: W3SecuritySecurityScan@1
inputs:
serviceConnectionEndpoint: 'myW3SecurityToken'
testType: 'container'
dockerImageName: 'my-container-image-name'
dockerfilePath: 'Dockerfile'
failOnIssues: true
monitorWhen: 'always'
Made with