What native CI/CD Integrations does AppCheck provide?
AppCheck currently offers a single fully-featured CI integration with JetBrains Teamcity. See https://appcheck.zendesk.com/hc/en-us/articles/360022084134-Integration-of-AppCheck-into-TeamCity for more details.
How can I integrate AppCheck into other CI/CD systems?
Other CI systems (eg Jenkins, TravisCI, and Atlassian Bamboo) can be integrated with using our API, which is documented at https://api.appcheck-ng.com/
Typically, clients wishing to integrate with their CI server would make a call to the API to trigger a scan following deployment of their code to a given environment, and then use either polling of scan state or else a webhookto determine the scan outcome and then decision the build flow from there. [The former is available via the API, and the latter is configurable in your scan portal under "Organisational Settings"]
Assuming you are using a CI server other than TeamCity, then you could, for example (other workflows are possible):
- Deploy your code to an instance (could be done at any stage such as test environment deploy)
- Create a new scan definition using the
method (https://api.appcheck-ng.com/apidoc-00.html) and passing in the targets parameter/api/v1/
(api_key)/scan/new
- Trigger a scan launch of your target using the
method (https://api.appcheck-ng.com/apidoc-01.html)/api/v1/
(api_key)/scan/
(scan_id)/start
- Either poll for scan status until completed using method
/api/v1/
(api_key)/scan/
(scan_id)/run/
(run_id) - method (https://api.appcheck-ng.com/apidoc-05.html) or else wait for webhook to fire notifying of scan completion
- Decision your build based on the data.vuln_counts count returned from the above method, or else call
method (https://api.appcheck-ng.com/apidoc-05.html) to get a full list of vulnerabilities and decision based on more advanced logic such as delta from last run etc./api/v1/
(api_key)/scan/
(scan_id)/run/
(run_id)/vulnerabilities
What do I need to bear in mind when integrating AppCheck scans into my CI/CD pipelines?
When running a scan from a CI pipeline, the scan time can be critical so as to not slow down deployment greatly. These are two things to consider here:
- If you have only made changes to one portion of your application code, then the scan scope for your scan can be limited using the pipe (|) delimiter suffix syntax to scan only a given path;
- The default scan profile "Standard" is relatively intensive, but it is possible to configure the scan quite extensively down to individual scan plugin level in order to provide a quicker and more highly focused scan of given concerns (eg XSS/form injection) only.
General principles of CI integration also apply such as that you'll almost certainly want to run the vulnerability scanning in "informational" mode at least initially and always pass the build regardless of scan outcome until you gain assurance in the resilience of the workflow developed.
Comments
0 comments
Please sign in to leave a comment.