Scanning with the CodeLogic .NET Agent (Docker)
The CodeLogic .NET Agent for Docker provides an easy way to integrate CodeLogic scanning into your build process.
Run the Docker Image
Pull and run the .NET agent image from your CodeLogic server registry:
docker run --pull always --rm --interactive \
--env CODELOGIC_HOST="https://yourinstance.app.codelogic.com/codelogic/server/" \
--env AGENT_UUID="your-agent-uuid" \
--env AGENT_PASSWORD="your-agent-password" \
--volume /path/to/scan:/home/codelogic/analysis_target \
yourinstance.app.codelogic.com/codelogic_dotnet:latest analyze \
--application "Your Application" \
--path /home/codelogic/analysis_target/
Docker options:
- --pull always — ensures that you always get the newest image
- --env CODELOGIC_HOST — CodeLogic server URL
- --env AGENT_UUID / --env AGENT_PASSWORD — agent credentials
- --volume — mounts the host directory to scan into the container
- See Docker Documentation for more options.
Tip
You can copy and paste the command directly into your Jenkins file.
analyze an application, omit the -d option if no database is utilized
analyze -a dynamicDemoApp --path /scan -d jdbc:postgresql://localhost:5432/sampledb
For more information, see Binary Scanning via Command Line (.NET).
CI/CD Scanning
Using the Docker agent with Jenkins
The CodeLogic .NET Agent for Docker can be used to scan artifacts in Jenkins pipelines.
Example:
stage('CodeLogic Scan EKS') {
when {
expression { BRANCH_NAME ==~ /(integration|v.*|feature\/.*)/ }
}
steps {
catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
// Publish CodeLogic Scan
sh('''
docker run --pull always --rm --interactive \
--env CODELOGIC_HOST="https://yourinstance.app.codelogic.com/codelogic/server/" \
--env "AGENT_UUID=${AGENT_UUID}" \
--env "AGENT_PASSWORD=${AGENT_PASSWORD}" \
--volume "${WORKSPACE}/NetCape/installdir":/home/codelogic/analysis_target \
yourinstance.app.codelogic.com/codelogic_dotnet:latest analyze \
--application "Your Application" \
--path /home/codelogic/analysis_target/ \
--scan-space-name "Development" \
--filter Example \
--method-filter Example \
--recursive com.example \
--rescan \
--expunge-scan-sessions
''')
}
}
}
Important
ScanSpaces should be unique to users or processes to avoid the inadvertent removal of previous scan sessions. The --expunge-scan-sessions option removes all previous scan sessions with the same fingerprint, even if they were created by another user.
The fingerprint is a collection of parameters specified when scanning. In the example below, the Java agent fingerprint is these parameters:
--application, --method-filter, --path, --scan-space-name, and --type.
For example, a Continuous Integration (CI) pipeline scan, perhaps in a Jenkinsfile, is initiated as part of a build whenever there is a code merge. These scans are stored by the CodeLogic Server in the Development ScanSpace.
The command in the Jenkinsfile is: analyze --application MyApplication --method-filter com.codelogic. --path /scan --type SCAN --scan-space-name Development.
A developer runs the same analysis using the CLI using CLI options that result in the same fingerprint but with the --expunge-scan-sessions option.
The developer's command is: analyze --application MyApplication --method-filter com.codelogic. --path /scan --type SCAN --scan-space-name Development --expunge-scan-sessions.
Since the fingerprints match, all previous scans in the Development ScanSpace on the CodeLogic server are removed.
This can be avoided by each user using their own ScanSpaces. A ScanSpace is created when the --scan-space-name option is used, if it does not already exist.
Although a default ScanSpace is used if none is specified, always specifying a ScanSpace that is unique to a user is recommended.