Travis CI
Travis CI is a Continuous Integration / Continuous Delivery (CI/CD) platform that enables developers to quickly and easily build, test and deploy code. The easy-of-use and flexibility offered by Travis CI is core to software development as part of a modern DevOps toolchain. Travis CI supports the development process by automatically building and testing code changes in smaller increments, providing immediate feedback on the success of the change. | |
Depending on the use case, you can apply multiple options for running scans from your CI pipeline. |
To get started with Travis CI using Github
- Go to Travis CI and Sign up with Github.
- Click on your profile picture on top right corner, click Settings and then Activate green button. After that choose GitHub repositories you want to use with Travis CI or select all repositories.
- Add a .travis.yml file to your repository to tell Travis CI what to do.
Configure and build a scan
Prerequisites:
-
Make a valid organization or personal API key (BRIGHT_TOKEN) with all or following scopes: bot, scans : run, scans : read, scans : stop.
-
Create BRIGHTTOKEN variable on your Travis CI machine:
_More options > Settings > Add Environment Variables.
Configure a .travis.yml file:
language: node_js
node_js:
- 10
before_script:
- npm install @neuralegion/nexploit-cli -g || true
script:
- printf "Start Nexploit Scan 🏁"
- >
SCAN_ID=$(nexploit-cli scan:run
--token $NEXPLOIT_TOKEN
--name "Test Travis Scan"
--crawler https://brokencrystals.com/
--smart)
- printf "Scan was started with ID https://nexploit.app/scans/$SCAN_ID\n"
- printf "Wait for issues ⏳\n"
- >
(nexploit-cli scan:polling
--interval 30s
--timeout 20m
--token $NEXPLOIT_TOKEN
--breakpoint medium_issue $SCAN_ID)
allow_failure: true
after_script:
- printf "Stop Scan 🛑"
- nexploit-cli scan:stop --token $NEXPLOIT_TOKEN $SCAN_ID
Add the .travis.yml file to your repository branch and commit to trigger a Travis CI build:
The scan is configured to stop when a medium issue is detected.
Monitoring the scan progress and checking issues:
Configure and build a scan with the repeater
Prerequisites:
-
Make a valid organization or personal API key (BRIGHT_TOKEN) with all or following scopes: bot, scans : run, scans : read, scans : stop.
-
Make the Repeater with a valid ID “REPEATER”.
-
Create the BRIGHTTOKEN and REPEATER variable on your Travis CI machine: _More options > Settings > Add Environment Variables.
Configure the .docker-compose.yml file.
Add a .docker-compose.yml file to your repository on another branch and commit the file:
Configure .travis.yml file:
Add the .travis.yml file to your same repository branch and commit to trigger a Travis CI build:
Monitoring the scan progress and checking issues:
The scan is configured to stop when a medium issue is detected.
Use Cases
Scanning a target in private environment
You can run fast scans of the application which is currently under development within your pipeline. Bright allows you to follow the fail-fast principle by interrupting a scan automatically at the first detected vulnerability. Using this option, you are able to quickly and timely reveal and fix the security issues at the build level without delaying the whole development process.
As the scan target is closed within your pipeline, the Bright engine cannot access it directly from the cloud. In this case, you can use a Repeater which serves as a request-proxy between Bright and a scan target inside your private environment. You should first register (create) the Repeater in the Bright app, and then connect it to your pipeline using the generated Repeater ID.
To run scans directly from your pipeline, you need to install the Bright CLI. It provides an easy-to-use interface and multiple commands you can use in your Travis flow.
You can either run the Bright CLI with the Repeater using the NPM or by installing the Bright's Docker image inside your pipeline.
Find the examples here:
Scanning a target in public environment
Upon a release of a new build, you can run a complete scan of the target in the production or public pre-production environment. In this case, long scans will not interfere with the development process as compared to scanning in the private environment.
Depending on the access to the deployed target, you can run a scan using multiple options.
- If the scan target is accessible from the Internet:
Directly from the Bright app
From your pipeline using the Bright CLI (NPM implementation). Find the example here.
- If the scan target has a private access (or if you want to scan specific local microservices), you can use a Repeater (scan proxy) to ensure secure communication between Bright and the scan target. In this case, you can only control scanning via the Bright CLI, which can be installed using either the NPM or the Docker image.
Find the examples here:
Updated about 2 months ago