Software Risk Manager

Documentation (v2025.3.5)
Contents

Contents

1. Software Risk Manager User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Getting Started with Software Risk Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Software Risk Manager Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Software Risk Manager Support Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Running a Basic Analysis with Sample Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
User Configuration Settings (My Settings) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Configuring Software Risk Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Adding and Configuring Project Metadata Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
API Keys Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Managing User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Triage Approval Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Manual Entry Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Triage Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Polaris Assist (Beta) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Add-In Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Assigning Tags to Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Server Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
License Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Project Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Working with Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Using Filters to Find Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Adding a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Configuring a Project Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Configuring Tools for a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Configuring Tool Connectors for a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Supported Tool Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Qualys VM Tool Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Scheduling Auto Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Analyzing Code in a Git Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Issue Tracker Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Advanced Field Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

ii
 Contents

Expression Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Expression Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Enumerable Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Issue Tracker Two-way Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Automatic Status Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Automatic Issue Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Configuring Project Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Tool Service Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Orchestrated Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Intelligent Orchestration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Policies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Policy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Creating and Editing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Applying a Policy to a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Applying a Policy to Multiple Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Monitoring Policy Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Integrations Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Integrated Development Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Issue Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Source Code Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Bulk Onboarding with GitHub Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Analyses Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Built-In Open Source Code Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Bundled Open Source Tool Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Built-In Open Source Dependency Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Importing Scan Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Aqua SaaS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
JFrog Xray Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Parasoft Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
SonarQube Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Starting an Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Starting an Analysis Using the Web Interface . . . . . . . . . . . . . . . . . . . . . . . . 219
Starting an Analysis Using the API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Tool Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

iii
Contents

Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Scan Request File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Adding an AppSec Testing Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Tool Status and Severity Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
SAST Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
DAST Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
IAST Tools Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Mobile Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
InfraSec Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Threat Modeling Tools Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Component Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Container Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Cloud Infrastructure Tool Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Infrastructure as Code (IaC) Tool Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 279
WAF Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
STIG Tools Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Tool First Seen Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Correlation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Understanding Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Understanding Data Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Understanding Location-based Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Understanding Component Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Understanding Hybrid (SAST/DAST) Correlation . . . . . . . . . . . . . . . . . . . . . 293
Understanding InfraSec Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Understanding Location-less Correlation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Findings Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Searching for Specific Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Working with Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using Filters to Display Findings Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Configuring Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Using Time Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
CWE Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Performing Bulk Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Change Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Change Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Override Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Bulk Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Issue Tracker Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

iv
 Contents

Managing Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Set Fix By Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Findings Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Analysis Input List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Adding Manual Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Using Machine Learning with Project Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Working with Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Working with Findings Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Generating a Findings Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Creating a Findings Report Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Working with Finding Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Details Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Severity Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Accessing Additional Training Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Activity Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Training Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Standard Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
HTTP Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
AI Insight Using Polaris Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Issue Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Predicted Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Fix By . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Triage Status Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Finding Status Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Project Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Hybrid Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Agentless Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Agentless Correlation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Agentless Correlation Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Rule Identifying Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Rule Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

v
Contents

Host Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Hosts Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Visual Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Visual Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Visual Log Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Webhooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

2. Software Risk Manager Install Guide . . . . . . . . . . . . . . . . . . . . . . . . 391

Software Risk Manager Install and Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Installation Requirements for the Native Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Installation Using the Native Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Linux Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Admin Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Data Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Protocol Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Web Server Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
MariaDB Database Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
SSL Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Generate an SSL Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Trusting Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Tomcat Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Time Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
License File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Uninstallation or Reinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Restoring to a Previous Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Manage Software Risk Manager Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Installation Using Docker Compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Software Risk Manager Core Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Docker Compose Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Configuration Tasks (Pre-work) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Persistent Storage Pre-work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
External Web Database Pre-work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Trust Certificates Pre-work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
HTTPS Pre-work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Software Risk Manager Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

vi
 Contents

Installation Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Volume Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Installation without an External Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Installation with an External Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Customizing Software Risk Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Back Up and Restore Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Creating a Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Backup Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Restoring a Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Upgrading Software Risk Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Running Software Risk Manager After Upgrade . . . . . . . . . . . . . . . . . . . . . . 432
Migrating from the Software Risk Manager Native Installer to Docker Compose . . 432
Migration Without an External Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Migration With an External Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Installation Using Kubernetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Manual Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Software Risk Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Understanding the AppData Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Enabling Intelligent Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Database Connection Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Internet Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
External URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Active Directory/LDAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
SAML Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Account Lockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Password Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Header-Based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
External User Auto-Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Cookie Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Session Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
EULA Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Data Retention Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Git Related Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Job Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Analysis Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

vii
Contents

Report Configuration Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Finding Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Tool Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
JVM System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Visual Log Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Tool Orchestration Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Issue Tracker Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Machine Learning Triage Server Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Automatic Updating of the Software Risk Manager Prediction Model . . . . . . . . . . . 476
Secure Code Warrior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Software Risk Manager Scoring Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
SMTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Host Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Webhook Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Polaris Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Customizing the Policy Email Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Configuring Automatically Deactivating Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

3. Software Risk Manager Plugins Guide . . . . . . . . . . . . . . . . . . . . . . . 480

Software Risk Manager Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Job Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
TeamCity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Bamboo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Findings View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Finding Details View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

viii
 Contents

Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Running an Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
IntelliJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Burp Suite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Sending Results to Software Risk Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
OWASP ZAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Sending Results to Software Risk Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Using Software Risk Manager with Splunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
GitHub Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Black Duck Bridge CLI Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Configuring Coverity Thin Client for use with Black Duck Bridge CLI and SRM . . . 536

4. Software Risk Manager API Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

Software Risk Manager API Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Software Risk Manager API Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

ix
Software Risk Manager Documentation (v2025.3.5)

1
Software Risk Manager User Guide
Getting Started with Software Risk Manager

Software Risk Manager (SRM) is a complete application security posture management (ASPM) solution.
SRM enables you to set up policy-driven workflows to orchestrate AST tools like Coverity and Black Duck,
prioritize issues, and monitor compliance across your software assets.
Software Risk Manager allows you to do the following with your AppSec data:

• Correlate results
• Prioritize vulnerabilities
• Track remediation
• Centralize risk visibility

SRM also provides issue tracking functionality as well as policy management solutions.

About This Guide

This guide provides descriptions of SRM functionality and instructions to maximize SRM deployment.
Additional information can be found in the following guides:

• Software Risk Manager Installation Guide. This guide provides instructions for installing and configuring
Software Risk Manager on Windows and Linux platforms.
• Software Risk Manager Plugins Guide. This guide provides information and instructions for integrating
Software Risk Manager with a variety of development tools and environments.
• Software Risk Manager API Guide. This guide documents the various REST resources provided by
Software Risk Manager, which allows external applications and scripts to interface with SRM core
functionality.
• Black Duck Bridge CLI. This guide explains how to run scans and receive results from the command
line.

Conventions Used in this Guide

The following conventions are used in this guide:

• Page names. The Software Risk Manager UI consists of a series of pages. The name of the page
appears in the top-left corner of the screen. In this guide, the page name begins with a capital letter. For
example, the Settings page.
• Button names. Tasks are performed by clicking buttons. The button name begins with a capital letter.
For example, Click Save.
• Icons. Icons appear throughout the Software Risk Manager UI. Icons can provide a visual indication of

10
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

a state or status, such as a policy violation. Icons can also serve as links to other pages. In this guide,
the icons are indicated by the name of the icon, beginning with a capital letter. For example, Click the
Settings icon.
• Menu items. Several pages in Software Risk Manager include sub-pages, which are listed as menu
items along the top or left of the screen. A menu item begins with a capital letter. For example, Select
License from the top menu.
• Dropdown configuration options. When working with certain elements, such as a project or finding, a
configuration icon appears to the right of the page. The icon appears as three horizontal dots. Clicking
this icon displays a dropdown list of options. Options appear in this guide by name, starting with a
capital letter. For example, Click the project's dropdown configuration icon and select New Analysis.
• Code strings and filenames. Code strings and filenames are shown in a mono-spaced font. For
example, Enter the following command: run srm.install

Note: A command that is designated as "code" needs to be entered exactly as shown.

Software Risk Manager Navigation

The Software Risk Manager UI consists of a series of pages, sub-pages, menus, buttons, and so on. Each
page includes common elements for navigation, as can be seen the sample image below and the
descriptions that follow.

The Software Risk Manager UI is structured around seven main pages:

• Projects. This page shows all the currently defined projects in Software Risk Manager.
• Findings. This page displays all the findings from a selected analysis.
• Policies. This page lists all the currently defined policies, policy violations, and other policy-related data
• Integrations. This page provides links to all the tool integrations supported by Software Risk Manager.
• Reports. This page provides a list of existing reports and allows you to create reports to automatically
be run on a custom schedule based on saved filters from the Findings page.
• Hosts. This page lists the currently defined hosts and host-related data.
• Settings. This page provides links to sub-pages where you can configure SRM. The Settings page and
sub-pages allow you configure users, define user groups, view server logs, and so on.

11
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

These pages are accessed by clicking their respective icons (links) in the SRM navigation bar, as shown in
the figure below.

Clicking an icon from the navigation bar opens the corresponding page. The name of the page appears in
the top left of the screen.

Menus, when available, appear along the left side of the page. Clicking a menu option opens the
corresponding page.

12
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The dropdown configuration icon (three horizontal dots) is located to the right of a particular entity, such as
a project or a finding, and provides a dropdown list of options.

The menu in the top right corner of the screen provides additional options and information (from left to
right):

• Software version. This is the version number of the Software Risk Manager installation.
• In-app documentation. Click the question mark icon to access the Software Risk Manager
documentation set. Both PDF and web versions of the guides are available.
• Plugin downloads. Click the plugins download icon to display a list of plugin options you can
download.
• Settings. Click the settings icon to access the Software Risk Manager visual log.
• [username]. Click the username icon to access the My Settings page or to log out of Software Risk
Manager.

13
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Software Risk Manager Deployment Options

Software Risk Manager has several deployment options, depending on your AppSec environment and
requirements. The most common SRM deployment options are as follows:

• Data aggregation
• Tool orchestration (requires the SRM Tool Orchestration module deployed on Kubernetes)
• SRM coupled with SAST (requires the SRM Scan Farm module deployed on Kubernetes)
• SRM coupled with SCA (requires the SRM Scan Farm module deployed on Kubernetes)
• SRM coupled with SAST and SCA (requires the SRM Scan Farm module deployed on Kubernetes)

Data Aggregation from Multiple Sources

Software Risk Manager supports a large and growing list of tool connectors that can be used to collect and
aggregate data from multiple sources. In addition to providing risk assessment detail for each finding, SRM
provides policy violation management, dashboards, and a host of other features. For this deployment
option, SRM is installed as a standalone product in a Windows or Linux environment.

Data Aggregation with Tool Orchestration

SRM with tool orchestration enables AppSec teams to build their own custom pipeline and orchestrate all
scanning from a central location. If a required tool isn't currently supported, SRM allows teams to configure
any commercial or open source tool to work with SRM. This option requires the SRM Tool Orchestration
module and a Kubernetes deployment.

Software Risk Manager Coupled with SAST

This deployment option allows teams to run Coverity (SAST) scans seamlessly with SRM. This option
requires the SRM Scan Farm module deployed on Kubernetes.

14
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Software Risk Manager Coupled with SCA

This deployment option allows teams to run Black Duck (SCA) scans seamlessly with SRM. This option
requires the SRM Scan Farm module deployed on Kubernetes.

Software Risk Manager Coupled with SAST and SCA

This deployment option allows teams to run Coverity (SAST) and Black Duck (SCA) scans seamlessly with
SRM. This option requires the SRM Scan Farm module deployed on Kubernetes.

Software Risk Manager Support Information

Software Risk Manager supports the following browsers and configurations.

Supported Platforms
Software Risk Manager APIs are compatible with any operating system and hardware that can connect to
the SRM server or APIs via HTTPS.

Browser Support
The SRM web UI can be accessed using any of the supported browsers shown in the following table:
Table 1.
Browser Versions Provider
Firefox Latest Versions supported by Mozilla
Google Chrome Latest Versions supported by Google
Microsoft Edge Latest Versions supported by Windows 10
Safari Latest Versions supported by Apple

Scan Farm Supported File Types and Tests

Note: Supported file types and tests apply to integrated Coverity and Black Duck only.

SAST Language Support

SRM supports the following SAST languages:

15
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
Language CI via Black Duck
Language Code Upload (UI) Git Integration
Versions Bridge CLI (CLI)
Salesforce Apex Supported Supported Supported
C++23
C++20
C++98
C++03
C++11
C/C++ Not Supported Not Supported Supported
C++14
C++17
C89
C99
C11

C# Up to C# 12 Supported Supported Supported

Dart Version Agnostic Supported Supported Supported
Go Go 1.20–1.21 Not Supported Not Supported Supported
Java Up to Java 21 Supported Supported Supported
JavaScript ECMAScript 2023 Supported Supported Supported
Kotlin 1.8.0-1.8.22, 1.9.0 Not Supported Not Supported Supported
Objective-C/C++ Not Supported Not Supported Supported
PHP Version Agnostic Supported Supported Supported
Python Python 3.x–3.11 Supported Supported Supported
Matz's Reference
Impl. (MRI)
1.9.2–3.2 and
Ruby equivalents (via Supported Supported Supported
Breakman pro
bundles into
analysis kit)
Swift Version Agnostic Supported Supported Supported
TypeScript TypeScript 1.0–5.2 Supported Supported Supported
Up to Visual Basic
Visual Basic Not Supported Not Supported Supported
16

16
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Infrastructure as Code: Static Testing

SRM supports the following Infrastructure as Code Static Testing.
Table 3.
CI via Black Duck
Language What is supported Code Upload (UI) Git Integration
Bridge CLI (CLI)
Platforms: AWS
CloudFormation,
Kubernetes,
Terraform.
IaC Supported Supported Supported
Formats: HCL
(Terraform), JSON,
XML, YAML

SCA Language and Package Manager Support

SRM supports the following SCA languages and package manager support:

17
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 4.
Package Supported Detectors,
Language Test Mode Supported Entry Point Accuracy
Manager Requirements
Code upload or
Not Supported
SCM integration
Apache Ivy Various Ivy Build Parse
Black Duck
Bridge CLI (CI/ Supported Ivy Build Parse Low
• Files: ivy.zml, build.zml
CLI)

Code upload or
Not Supported
SCM integration
BitBake Various Black Duck
Bridge CLI (CI/ Supported Bitbake CLI
CLI)
Code upload or
Not Supported
SCM integration
Cargo Lock
Cargo Rust Black Duck
Bridge CLI (CI/ Supported Cargo Lock • Files: Cartfile, High
CLI) Cartfile.resolved

Code upload or
Not Supported
SCM integration
Carthage Lock
Carthage Various Black Duck
Bridge CLI (CI/ Supported Carthage Lock • Files: Cartfile, High
CLI) Cartfile.resolved

18
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements
Code upload or
Not Supported
SCM integration
CocoaPods Objective-C Pod Lock
Black Duck
Bridge CLI (CI/ Supported Pod Lock High
• Files: Podfile.lock
CLI)

Code upload or
Not Supported
SCM integration
Conan Lock
High
• Files: conan.lock

Conan Lock Conan CLI

Conan C/C++ • Files: conanfile.txt or

Black Duck High
conanfile.py
Bridge CLI (CI/ Supported
• Executables: conan
CLI)

Conan CLI

• Files: conanfile.txt or
Conan CLI High
conanfile.py
• Executables: conan

Code upload or
Not Supported
SCM integration
Conda Python
Black Duck
Supported Conda CLI Conda CLI High
Bridge CLI (CI/

19
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Files: environment.yml
CLI)
• Executables: conda

Code upload or
Not Supported
SCM integration
Cpan CLI
CPAN Perl Black Duck
Bridge CLI (CI/ Supported Cpan CLI • File: Makefile.PL High
CLI) • Executables: cpan

Code upload or
Not Supported
SCM integration
CRAN R Packrat Lock
Black Duck
Bridge CLI (CI/ Supported Packrat Lock High
• File: packrat.lock
CLI)

Code upload or
Not Supported
SCM integration
Dart CLI

Dart Dart Black Duck • Files: pubspec.yaml,

High
Bridge CLI (CI/ Supported Dart CLI pubspec.lock
CLI) • Executables: dart, flutter

Dart PubSpec Lock High

20
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Files:
pubspec.yaml,pubspec.lo
ck

Dart PubSpec Lock

Dart PubSpec • Files:

High
Lock pubspec.yaml,pubspec.lo
ck

Code upload or
Not Supported
SCM integration
Go Dep Golang (Go) GoDep Lock
Black Duck
Bridge CLI (CI/ Supported GoDep Lock High
• File: Gopkg.lock
CLI)

Code upload or
Not Supported
SCM integration
Go Gradle Golang (Go) GoGradle Lock
Black Duck
Bridge CLI (CI/ Supported GoGradle Lock High
• File: gogradle.lock
CLI)

Code upload or
Not Supported
SCM integration
Go Modules Golang (Go) Black Duck
Bridge CLI (CI/ Supported GoMod CLI GoMod CLI High
CLI)

21
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Files: go.mod
• Executables: go

Code upload or
Not Supported
SCM integration
Go Vendor
Go Vendor High
• Files: vendor/vendor.json
Go Vendor Golang (Go) Black Duck
Bridge CLI (CI/ Supported
CLI) GoVndr CLI
GoVndr CLI High
• Files: vendor.conf

Gradle Project Inspector

Code upload or Gradle Project
Supported Low
SCM integration Inspector • Files: build.gradle

Gradle Native Inspector

Gradle Various
• Files: build.gradle or
Black Duck build.gradle.kts High
Gradle Native
Bridge CLI (CI/ Supported • Executables: gradlew or
Inspector
CLI) gradle

Gradle Project Inspector Low

22
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Files: build.gradle

Code upload or
Not Supported
SCM integration
Rebar CLI
Hex Erlang Black Duck
Bridge CLI (CI/ Supported Rebar CLI • Files: rebar.config High
CLI) • Executables: rebar3

Code upload or
Not Supported
SCM integration
Lerna CLI

• Files: lema.json,
Lerna Node.js package.json
Black Duck
• Executables: Lerna, and
Bridge CLI (CI/ Supported Lerna CLI High
one of the following:
CLI)
• packagelock.json
• npmshrinkwrap.json
• yarn.lock

Maven Project Inspector

Code upload or Maven Project
Supported Low
SCM integration Inspector • Files: pom.xml
Maven Various
Black Duck
Supported Maven CLI Maven CLI High
Bridge CLI (CI/

23
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Files: pom.xml
• Executables: mvnw or
mvn

Maven Project Inspector

Low
• Files: pom.xml

CLI) Maven Wrapper CLI

• Files: pom.groovy
High
• Executables: mvnw or
Maven Wrapper mvn
CLI
Maven Project Inspector
Low
• Files: pom.xml

NPM Package Lock

NPM Package • Files: packagelock.json.

High
Lock For better results, include
Code upload or a package.json also.
npm Node.js Supported
SCM integration
NPM Package Json Parse
NPM Package
Low
Json Parse • Files: package.json

24
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements
NPM Shrinkwrap

• Files: npm-
shrinkwrap.json. For High
better results, include a
package.json also.

NPM Package Lock

• Files: packagelock.json.
High
For better results, include
NPM Shrinkwrap package.json also.

Black Duck NPM CLI

Bridge CLI (CI/ Supported
CLI) • Files node_modules,
High
package.json
• Executables: npm

NPM Package Json Parse

High
• Files: packagelock.json

NPM Package Lock

NPM Package • Files: packagelock.json.

High
Lock For better results, include
a package.json also.

25
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements
NPM CLI

• Files: node_modules,
High
package.json
• Executables: npm

NPM Package Json Parse

Low
• Files: package.json

NPM CLI

• Files: node_modules,
High
package.json
• Executables: npm
NPM CLI

NPM Package Json Parse

Low
• Files: package.json

NPM Package Json Parse

NPM Package
Low
Json Parse • Files: package.json

NuGet Solution Native

Inspector
NuGet Solution
NuGet C# All Supported High
Native Inspector
• Files: A solution file with a

26
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

.sln extension

NuGet Project Inspector

• Files: A project file with

Low
the .csproj or .sln
extension

NuGet Project Native

Inspector

• Files: A project file with

the csproj, .fsproj, .vbproj,
.asaproj, .dcproj, .shproj,
.ccproj, .sfproj, .njsproj,
High
.vcxproj, .vcproj, .xproj,
.pyproj, .hiveproj, .pigproj,
NuGet Project .jsproj, .usqlproj,
Native Inspector .deployproj, .msbuildproj,
.sqlproj, .dbproj, or .rproj
extension

NuGet Project Inspector

• Files: A project file with

Low
the .csproj or .sln
extension

27
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements
Code upload or
Not Supported
SCM integration
Composer Lock
Packagist PHP Black Duck
Bridge CLI (CI/ Supported Composer Lock • Files: composer.lock, High
CLI) composer.json

Code upload or
Not Supported
SCM integration
Pear CLI
PEAR PHP Black Duck
Bridge CLI (CI/ Supported Pear CLI • Files: package.xml High
CLI) • Executables: pear

Pipfile Lock
Code upload or
Supported Pipfile Lock • Files: Pipfile or High
SCM integration
Pipfile.lock

Pipfile Lock
pip Python
• Files: Pipfile or
Black Duck Pipfile.lock High
Bridge CLI (CI/ Supported Pipenv Lock • Executables: python or
CLI) python3, and pipenv

PIP Native Inspector High

28
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Files: setup.py, or one or

more requirements.txt
• Executables: python and
pip, or python3 and pip3

Pipfile Lock
High
• Files: Pipfile, Pipfile.lock

PIP Native Inspector

• Files: setup.py, or one or

more requirements.txt High
• Executables: python and
Pip Native pip, or python3 and pip3
Inspector

Pipfile Lock
High
• Files Pipfile, Pipfile.lock

Pipfile Lock
Pipfile Lock High
• Files: Pipfile, Pipfile.lock

Pnpm Lock
pnpm Node.js All Supported Pnpm Lock High
• Files pnpmlock.yaml,

29
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

package.json

Poetry Lock

Poetry Python All Supported Poetry Lock • Files Poetrylock, High

pyproject.toml

Code upload or
Not Supported
SCM integration
Gemfile Lock
High
• Files: Gemfile.lock

Gemfile Lock Gemspec Parse

RubyGems Ruby Black Duck
• Files: A gemspec file with Low
Bridge CLI (CI/ Supported
the .gemspec extension
CLI)

Gemspec Parse

Gemspec Parse • Files: A gemspec file with Low

a .gemspec extension

Code upload or
Not Supported
SCM integration
SBT Scala
Black Duck Sbt Native
Supported Sbt Native Inspector High
Bridge CLI (CI/ Inspector

30
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Files: build.sbt
CLI) • Plugins: Dependency
Graph

Swift Lock
Code upload or
Supported Swift Lock • Files: Package.swift, High
SCM integration
Package.resolved

Swift Lock

• Files: Package.swift, High

Package.resolved
Swift Swift Swift Lock
Swift CLI
Black Duck
Bridge CLI (CI/ Supported • Files: Package.swift High
CLI) • Executables: swift

Swift CLI

Swift CLI • Files: Package.swift High

• Executables: swift

Code upload or
Not Supported
Xcode Swift SCM integration
Black Duck Supported Xcode Xcode Workspace Lock High

31
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Supported Detectors,

Language Test Mode Supported Entry Point Accuracy
Manager Requirements

• Directories:
*.xcworkspace

Workspace Lock Xcode Project Lock

Bridge CLI (CI/ • Directories: *.xcodeproj

CLI) • Files: Package.resolved

Xcode Project Lock

Xcode Project
• Directories: *.xcodeproj
Lock
• Files: Package.resolved

Yarn Lock

Yarn Node.js All Supported Yarn Lock • Files: yarn.lock, High

package.json

32
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SCA Package Manager Versions

SRM supports the following SCA package manager versions:

Note: Package manager version requirements are only applicable to tests created with Black Duck
Bridge CLI (when testing relies on/requires access to executables). "N/A" in the table below indicates
buildless capture is used to test projects that depend on the package manager.

Table 5.
Package Manager Latest Supported Version
Apache Ivy N/A
Bazel 4.2.0
BitBake 2.6.0 (Yocto 4.3.2)
Cargo N/A
Carthage N/A
CocoaPods N/A
Conan 2.0.14
Conda 4.10.3
Cpan Script 1.678
CPAN CPAN.pm 2.36
Cpanm 1.7047

CRAN N/A
Dart 3.1.2
Dart
Flutter 3.13.4

Go 1.20.4
Go Dep N/A
Gogradle N/A
Go Modules 1.20.4
Go Vendor N/A
Gradle 8.2.1
Hex Rebar 3.20.0
Lerna 6.6.2

33
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Package Manager Latest Supported Version

Maven 3.8.1
Node 20.5.1
npm
npm 9.8.1

nuget 6.2
NuGet
.NET runtime is not required with 7.13.0

Packagist N/A
PEAR 1.10.12
pip 23.1.2
pnpm N/A
Poetry N/A
RubyGems 2.0.0
SBT 1.5.0
Swift 5.6.1
Xcode N/A
Yarn 4.1.0

Running a Basic Analysis with Sample Data

To provide an overview of how to use Software Risk Manager to run an analysis, the following is an outline
of the process:

1. Make sure SRM has been installed and configured.

2. Launch the app and log in.
3. Create a project.
4. Configure the parameters for a new analysis.
5. Upload the source files.
6. Manually start a New Analysis for the project.
SRM will begin analyzing the code. (The analysis will run in the background until complete.)
7. Inspect the findings from the project Findings page or the Dashboard.

Sample Data Sets

If you would like to use sample code for testing purposes, the following are some datasets that are all
intentionally vulnerable applications used for educational and training purposes. They're referenced by
their primary language, although some of them are multi-language.

34
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Java - WebGoat
We recommend you use one of the WebGoat released war files directly as the input for Software Risk
Manager since those tend to package everything, including the source, bytecode, and third-party
dependencies. For instance, try this release.
• .NET - WebGoat.NET
Since the Software Risk Manager .NET scanners require compiled assemblies, you will need to
download the WebGoat.NET source and build it on your machine. Instructions for how to do so are at
the link above.

For the following datasets, you can configure your new project's Git Config to fetch the source directly from
GitHub using their git URL.

• Ruby on Rails - RailsGoat

git URL: https://github.com/OWASP/railsgoat.git
• JavaScript - NodeGoat
git URL: https://github.com/OWASP/NodeGoat.git

For other datasets, we recommend that you browse GitHub for different projects and scan some of them
for testing purposes. Here are some queries to get you started:

• Java
• C
• C++
• PHP
• Scala
• Python
• Ruby on Rails
• JavaScript

User Configuration Settings (My Settings)

User Configuration settings, or "My Settings," allows you to set notifications, manage passwords, and
configure personal access tokens, which can be used to access the Software Risk Manager REST API.
Click your username in the upper right corner of the page and select My Settings to open the My Settings
page.

35
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information on user configuration settings, see the following topics:

• Configuring email notifications

• Changing your password
• Managing personal access tokens

Configuring Email Notifications

Email notifications allow you to receive emails when a policy status changes or when there's an analysis
failure. (For more information on polices and policy status, see the Policies Overview section.)
To configure email notifications:

1. Click your username in the upper right corner of the page and select My Settings from the dropdown
menu.

2. Select Notifications from the top menu to open the Notifications page.

3. Enter your email address in the Email field.

4. Use the toggles to enable email notifications.

36
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

There are four notification options:

• Project Policy status email notifications. Sends an email when there's a policy status change for
a project.
• Analysis failure email notifications. Sends an email when there is an analysis failure for a
project.
• Upcoming API Key expirations. Sends an email when an API Key is due to expire.
• Upcoming Personal Access Token expirations. Sends an email when a Personal Access Token
is due to expire.
Changes are saved automatically.

Changing Your Password

Users can change their own password from the My Settings page. (Admins can also change user
passwords. See Changing a User Password.)
To change your password:

1. Click your username in the upper right corner of the page and select My Settings from the dropdown
menu.

2. Select Password from the top menu.

3. Enter your current password.

4. Enter and confirm your new password.
Passwords must be at least 12 characters.
5. Click Change Password.

37
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Managing Personal Access Tokens

The Personal Access Tokens page displays a list of users and usage data and allows you to generate a
new token or delete an existing one.

Viewing Existing Tokens

To view personal access tokens:

1. Click your username in the upper right corner of the page and select My Settings from the dropdown
menu.

2. Select Personal Access Tokens from the top menu.

This page displays the existing tokens and usage data. Click the column headers to sort the list.

Generating Personal Access Tokens

To generate a personal access token:

1. Click your username in the upper right corner of the page and select My Settings from the dropdown
menu.

38
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Select Personal Access Tokens from the top menu.

This page displays the existing tokens and usage data.

3. Click Generate Token to create a new personal access token.

4. Enter a name for the token.

5. Select an expiration. (The default is 90 days.)
6. Select permission options:
• Inherit all of my permissions. The token will include all of your configured roles.
• Inherit specific permissions (Read, Create, Update, Manage). The token will inherit the selected
roles only. For example, selecting "Read" will allow the token to read any project where you have
the "Read" permission set.

39
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: This setting will not override or grant permissions that a user doesn't already have.

7. Click Generate Token.

8. Copy and save your new token.

Once this window is closed, the token cannot be redisplayed.
9. Click Done to close the window.

Deleting a Token
To delete a personal access token:

1. Click your username in the upper right corner of the page and select My Settings from the dropdown
menu.

2. Select Personal Access Tokens from the top menu.

40
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Locate the token you want to delete and click Delete Token.

4. Click Delete to confirm.

Configuring Software Risk Manager

The Settings pages are used to configure Software Risk Manager.

Click the Settings icon in the left navigation bar to open the Settings page.

41
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Select a settings option from the left menu to open the corresponding Settings page. The page currently
being displayed is shown in the top left corner.
For detailed information on each page, see the following topics:

• Users. Add new users, configure user roles, manage existing user profiles, and so on.
• User Groups. Create and manage groups of users.
• Roles. Create and Manage Roles.
• API Keys. Generate and configure API keys.
• Project Metadata. Create, define, and configure custom metadata for projects.
• Triage Approval Workflow. Configure how status change requests are handled.
• Manual Entry Config. Define custom values that can be entered into selected fields and added as
manual results in a findings report.
• Triage Assistant. Configure SRM to use previous triage determinations to make predictions about future
findings.
• Polaris Assist (Beta). Generate AI Insight information.
• Add-In Tools. Configure additional tools that can be used to analyze code.
• Tags. Create and manage tags that can be assigned to findings.
• License. View license information with an option to update the current license.
• Server Logs. View events and errors associated with an analysis.

User Administration

Before running an analysis, an admin needs to configure user profiles, which includes user roles,
permissions, group associations, and so on.

42
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: Users can be managed individually or in groups. (To manage user groups, see Managing User
Groups.)

Click the Settings icon in the navigation bar and select Users from the left menu to open the Users page.

This page displays a list of current users, the date the user last logged in, and whether that user is active.
Clicking the column headings will re-sort the list.
For more information on configuring user profiles, see the following topics:

• Viewing existing users

• Adding a user
• Configuring user profiles
• Changing a user password
• Deleting a user profile

Viewing Existing Users

The User page allows you to view a list of existing users, the date of their last login, and whether they are
active.

Note: The superuser's admin and active states may not be modified.

To view a list of existing users:

43
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. Click the Settings icon in the navigation bar and select Users from the left menu.

This page lists each user, when they last logged in, and whether they are "active."
2. Use the filter field to search for a specific user, or click the column headings to re-sort the list.

Adding a User
Admins can add three different types of users: Local, LDAP, and SAML (depending on your configuration).
To add a user:

1. Click the Settings icon in the navigation bar and select Users from the left menu.

44
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click Add User and select a user type.

There are three user types:
• Local Users. Local Users exist only within Software Risk Manager. You pick a username and
password for them. Software Risk Manager keeps their credentials in its database.
• LDAP Users. LDAP Users can be added to Software Risk Manager by their username, but their
password is managed by an external LDAP server. When an LDAP user logs in, Software Risk
Manager will send their credentials to that server in order to authenticate the user.
• SAML Users. SAML Users can be added to Software Risk Manager by their username, but
authentication is handled by an external SAML provider. When a user reaches the Login page,
Software Risk Manager will redirect them to the Sign On Portal of your SAML provider in order to
authenticate the user. They may see the standard Software Risk Manager Login page with a link to
sign in via SAML, depending on your configuration.

45
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Enter a name, password, and confirm the new password.

4. Use the toggles to set global permissions for the user.
• Administrator. Grants user admin privileges. Admin users inherit all roles.
• Project Administrator. Allows the user to create a new project.
• Integrations Administrator. Allows user to manage centralized project configuration.
• Policy Administrator. Allows user to create polices.
• API Key Administrator. Allows user to manage API Keys.
• Project Viewer. Allows user to view all projects.
5. Select which roles the user will have for each project.
• Read. The user or user group can see the specified project and all of its contents. If a user doesn't
have the Read role for a particular project, that project will not appear in the Projects page for that
user.
• Update. The user or user group can change the finding status and comment on findings for the
specified project.
• Create. The user or user group can create new analyses for the specified project
• Manage. The user or user group can manage the specified project's configuration (e.g., Git, Issue
tracker, etc.). The Manage role also allows the user to delete the specified project.
6. Click Create Local User.

Configuring a User Profile

Configuration settings in a user profile determines how a user interacts with Software Risk Manager
globally and what the user will be able to do on a project-by-project basis. Global permissions (or roles)
include Administrator, Project Administrator, and Integrations Administrator. Next, users can be assigned
specific roles for individual projects: Read, Update, Create, and Manage.

46
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: The Super User's admin and active states may not be modified.

To edit an existing user profile:

1. Click the Settings icon in the navigation bar and select Users from the left menu.

2. Click the dropdown configuration icon to the right of the user name and select Configure Roles.

This opens the "Configure Roles" window.

47
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Configure user roles as needed.

Click on a role to select it. Click Clear to remove all selections.
Global Permissions. Select global permissions for the new user.
• Administrator. Grants user admin privileges. Admin users inherit all roles.
• Project Administrator. Allows the user to create a new project.
• Integrations Administrator. Allows user to manage centralized project configuration.
• Policy Administrator. Allows user to create polices.
• API Key Administrator. Allows user to manage API Keys.
• Project Viewer. Allows user to view all projects.
Project Roles. Select permissions for individual projects.
• Read. The user or user group can see the specified project and all of its contents. If a user doesn't
have the Read role for a particular project, that project will not appear in the Projects page for that
user.
• Update. The user or user group can change the finding status and comment on findings for the
specified project.
• Create. The user or user group can create new analyses for the specified project
• Manage. The user or user group can manage the specified project's configuration (e.g., Git, Issue
tracker, etc.). The Manage role also allows the user to delete the specified project.
4. Click Save.

Changing a User Password

Admins can change the password of any user. (Users can change their own passwords on the My Settings
page. See Changing Your Password.)
To change a user's password:

48
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. Click the Settings icon in the navigation bar and select Users from the left menu.

2. Click the dropdown configuration icon to the right of the user name and select Change Password.

This opens the change password window.

3. Enter and confirm the new password.

Passwords must be at least 12 characters.
4. Click Save.

49
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Deleting a User Profile

Admins can delete one or more users.
To delete a user:

1. Click the Settings icon in the navigation bar and select Users from the left menu.

2. Click the dropdown configuration icon to the right of the user name and select Delete User.

3. Click Delete to confirm.

Adding and Configuring Project Metadata Fields

Project Metadata Fields allow Software Risk Manager users to create and configure custom metadata for
specified projects. Once a field has been defined, you can use that field to enter metadata values for
specified projects. For more information on adding metadata values to projects, see Configuring Project
Metadata.
Click the Settings icon in the navigation bar and select Project Metadata Fields from the left menu to open
the Metadata Fields page.

50
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Project Metadata Fields page lists currently defined field names and types. Clicking on the column
header will re-sort the list.
There are four field types:

• Text. A regular text input that allows a single line of text.

• Multiline. A larger text input that allows for multiple lines of text.
• Dropdown. Text input that a user can select from a dropdown list.
• Tags. A special input that behaves similarly to Text, but each individual word is converted to a "tag." As
you type, pressing the space bar will convert whatever text you already had into a tag. (A space is
required after the last tag.)

For more information on project metadata fields, see the following topics:

• Viewing existing project metadata fields

• Adding a project metadata field
• Editing a project metadata field
• Deleting a project metadata field

Viewing Existing Metadata Fields

To view a list of existing metadata fields:

1. Click the Settings icon in the navigation bar and select Project Metadata Fields from the left menu.

51
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This page shows the existing metadata fields and field type. There are four field types:
• Text. A regular text input that allows a single line of text.
• Multiline. A larger text input that allows for multiple lines of text.
• Dropdown. Text input that a user can select from a dropdown list.
• Tags. A special input that behaves similarly to Text, but each individual word is converted to a "tag."
As you type, pressing the space bar will convert whatever text you already had into a tag. (A space
is required after the last tag.)
2. Click on the column headers to re-sort the list.

Adding a Metadata Field

Metadata fields are defined by name and type.
To add a metadata field:

1. Click the Settings icon in the navigation bar and select Project Metadata Fields from the left menu.

52
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click Add Field.

3. Enter a name for the field and select a field type.

There are four field types:
• Text. A regular text input that allows a single line of text.
• Multiline. A larger text input that allows for multiple lines of text.
• Dropdown. Text input that a user can select from a dropdown list.
• Tags. A special input that behaves similarly to Text, but each individual word is converted to a "tag."
As you type, pressing the space bar will convert whatever text you already had into a tag. (A space
is required after the last tag.)
4. Click Save.

Editing a Metadata Field

For existing metadata fields, both the field name and field type can be edited.
To edit a metadata field:

1. Click the Settings icon in the navigation bar and select Project Metadata Fields from the left menu.

53
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the field's dropdown configuration icon and select Edit.

This opens the Edit Project Metadata Field window.

3. Make changes to the fields as needed.

4. Click Save.

Deleting a Metadata Field

Once a metadata field is no longer needed, it can be deleted.
To delete a metadata field:

54
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. Click the Settings icon in the navigation bar and select Project Metadata Fields from the left menu.

2. Click the field's dropdown configuration icon and select Delete.

3. Click Delete to confirm.

API Keys Administration

API Keys can be generated for use with the Software Risk Manager API. Typically one key would be
generated for a specific purpose, such as integrating with a specific tool or plugin. This would allow for
fine-grained control over each API key’s active/inactive state, as well as setting specific user roles for each
key. In addition, API keys can be subject to expiration (default is 90 days).
Click the Settings icon in the navigation bar and select API Keys from the top menu to open the API Keys
page.

55
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This page lists the currently assigned API keys, shows when they were last active, and if they are currently
active.

Note: For more information on Software Risk Manager API capabilities, please refer to the Software Risk
Manager API Guide.

For more information on administering API keys, see the following topics:

• Viewing existing API keys

• Creating an API key
• Editing an API key
• Regenerating an API key
• Deleting an API key

Viewing Existing API Keys

To view a list of existing API keys:

1. Click the Settings icon in the navigation bar and select API Keys from the left menu.

This page a list of existing API keys, the date of the most recent activity, and whether the key is active.
2. Use the filter field to search for a specific API key or click the column headings to re-sort the list.

56
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Creating an API Key

To create an API key:

1. Click the Settings icon in the navigation bar and select API Keys from the left menu.

2. Click Create New Key.

3. Enter a name for the new API Key.

4. Select an expiration. (The default is 90 days.)
5. Configure global permissions and project roles as needed.
Click on a role to select it. Click Clear to remove all selections.
Global Permissions. Select global permissions for the new user.
• Administrator. Grants user admin privileges. Admin users inherit all roles.
• Project Administrator. Allows the user to create a new project.
• Integrations Administrator. Allows user to manage centralized project configuration.

57
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Policy Administrator. Allows user to create polices.

• API Key Administrator. Allows user to manage API Keys.
• Project Viewer. Allows user to view all projects.
Project Roles. Select permissions for individual projects.
• Read. The user or user group can see the specified project and all of its contents. If a user doesn't
have the Read role for a particular project, that project will not appear in the Project List page for
that user.
• Update. The user or user group can change the finding status and comment on findings for the
specified project.
• Create. The user or user group can create new analyses for the specified project
• Manage. The user or user group can manage the specified project's configuration (e.g., Git, Issue
tracker, etc.). The Manage role also allows the user to delete the specified project.
6. Click Create API Key.

Editing an API Key

To edit an API key:

Note: The API token expiration cannot be edited; however, regenerating an API key allows you to set a
new expiration.

1. Click the Settings icon in the navigation bar and select API Keys from the left menu.

2. Click the dropdown configuration icon and select Edit API Key.

This opens the "Edit API Key" window.

58
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Configure global permissions and project roles as needed.

Click on a role to select it. Click Clear to remove all selections.
Global Permissions. Select global permissions for the new user.
• Administrator. Grants user admin privileges. Admin users inherit all roles.
• Project Administrator. Allows the user to create a new project.
• Integrations Administrator. Allows user to manage centralized project configuration.
• Policy Administrator. Allows user to create polices.
• API Key Administrator. Allows user to manage API Keys.
• Project Viewer. Allows user to view all projects.
Project Roles. Select permissions for individual projects.
• Read. The user or user group can see the specified project and all of its contents. If a user doesn't
have the Read role for a particular project, that project will not appear in the Projects page for that
user.
• Update. The user or user group can change the finding status and comment on findings for the
specified project.
• Create. The user or user group can create new analyses for the specified project
• Manage. The user or user group can manage the specified project's configuration (e.g., Git, Issue
tracker, etc.). The Manage role also allows the user to delete the specified project.
4. Click Save.

Regenerating an API Key

To regenerate an API key:

1. Click the Settings icon in the navigation bar and select API Keys from the left menu.

59
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the dropdown configuration icon and select Regenerate API Key.

This opens the "Regenerate Key" window.

3. Select an expiration period and click Regenerate API Key. (The default is 90 days.)
4. Copy and save the new API key and click Close.

Deleting an API Key

To delete an API key:

1. Click the Settings icon in the navigation bar and select API Keys from the left menu.

60
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the dropdown configuration icon and select Delete API Key.

3. Click Delete to confirm.

Managing User Groups

To simplify user administration, users can be managed as groups. Roles and permissions assigned to a
group will apply to every member of that group. Admins can set up multiple groups with multiple
permissions, including nested groups.
Click the Settings icon in the navigation bar and select User Groups from the left menu to open the User
Groups page.

The User Groups page shows a list of existing groups and the number of members in each. Clicking the
column headers will re-sort the list.

61
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information on managing user groups, see the following topics.

• Viewing existing user groups

• Creating a user group
• Configuring user group roles
• Editing user group settings
• Deleting a user group

Viewing Existing User Groups

To view a list of existing user groups:

1. Click the Settings icon in the navigation bar and select User Groups from the left menu.

This page shows a list of existing groups and the number of members in each.
2. Use the filter field to search for a specific user group or click the column header to re-sort the list.

Creating a User Group

In addition to single groups, groups can be nested ("parent" group).
To create a user group:

1. Click the Settings icon in the navigation bar and select User Groups from the left menu.

62
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click Create Group.

3. Enter a group name and select group members from the list.
4. (Optional) Select a "Parent Group" to create a nested group.
5. Click Save.

Configuring User Group Roles

Assigning roles to a group will apply those roles to every member of that group. However, roles assigned
to members in the group will not replace or overwrite the roles assigned individually to a user.
To configure group roles:

1. Click the Settings icon in the navigation bar and select User Groups from the left menu.

63
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the dropdown configuration icon and select Configure Roles.

This opens the Configure Roles window.

3. Make the necessary configuration changes.

4. Click Done.

Editing User Group Settings

Editing group settings includes changing the group name, reassigning the parent group, and adding or
removing users.
To edit group settings:

1. Click the Settings icon in the navigation bar and select User Groups from the left menu.

64
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the dropdown configuration icon and select Edit Group Settings.

This opens the Edit User Group window.

3. Make the necessary changes.

Use the filter field to search for individual users or click the column headers to re-sort the list.
4. Click Save.

65
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Deleting a User Group

Deleting a user group will not delete individual users or remove any roles previously assigned to a user
individually
To delete a user group:

1. Click the Settings icon in the navigation bar and select User Groups from the left menu.

2. Click the dropdown configuration icon and select Delete Group.

This opens the Confirm Delete window.

3. Click Delete to confirm.

66
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Configuring LDAP for User Groups

Note: To take advantage of LDAP with User Groups, there must be a valid LDAP configuration in the
Software Risk Manager properties file. For more information, see the SRM Install Guide.

This feature may be presented when LDAP is configured but is only compatible with providers that create a
user attribute containing group membership for SRM to check, such as Active Directory.
To manage mapping of LDAP groups to SRM user groups, pick the LDAP Config option from the group's
config menu.

From here, you can enter a comma-separated list of LDAP group names.

The names for your LDAP groups are pulled from the DN path attribute specified in the SRM properties
file. For more information, see LDAP group mapping in the SRM Install Guide.
When an LDAP user signs in, their LDAP groups will be checked against your mappings configured on this
page. The user will be added to the SRM group if they are a member of any of the listed LDAP groups;
otherwise, they will be removed.
If users are added or removed from an LDAP group, their membership will not be updated until they sign
out and back in. You can force a manual refresh of all group's LDAP members by clicking the "Refresh"
button on this page.

67
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: If the LDAP Group Names textbox is empty, a membership refresh will have no effect on that
group.

Triage Approval Workflow

Triage settings associated with findings can be changed by users with an admin or manage role. Users
who are unable to change the triage status directly can submit a change for approval. Admins can
configure the triage workflow from the Settings menu and define what users are allowed to do by
configuring user roles. Requests for changing triage status can be approved by admins.
Click the Settings icon in the navigation bar and select Triage Approval Workflow from the left menu to
open the configuration page.

Managing the Triage Approval Workflow consists of the following tasks:

• Configuring the triage workflow

• Configuring the workflow for all projects
• Configuring the workflow for specified projects
• Approving requests for status changes

Configuring Triage Workflow

This page provides three options for triage approval configuration:

• No triage approval workflow. Select this option to restrict the ability to change status to admins and
users with "update" or "manage" roles.
• Enabled triage approval workflow for all projects. Select this option to enable the approval workflow for
all current and future projects.
• Enable triage approval workflow, but allow it to be configured at the Project level. Select this option to
enable the workflow option on a project level.

Use the radio buttons to select an option. The selection will be saved automatically.

68
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information on changing the status of a finding, see the Change Status section.

Configuring Triage Workflow for All Projects

Admins can configure the triage approval workflow based on a specified project.
To configure the triage workflow for a project:

1. Click the Settings icon in the navigation bar and select Triage Approval Workflow from the left menu to
open the configuration page.

2. Select the "Enable triage approval workflow for all projects" to include all projects.

Configuring Triage Workflow for Specified Projects

Admins can configure the triage approval workflow based on a specified project.
To configure the triage workflow for a project:

1. Click the Settings icon in the navigation bar and select Triage Approval Workflow from the left menu to
open the configuration page.
2. Select the "Enable triage approval workflow for all projects" to include all projects, or select "Enable
triage approval workflow, but allow it to be configured at the Project level" for individual projects.
3. Open the Projects page, click the project's dropdown configuration icon, and select Triage Approval
Config.

69
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

4. Select one of the following options:

• Default (See Configuring Triage Workflow for All Projects.)
• No triage approval workflow
• Enable triage approval workflow

5. Click Save.

Creating a Status Change Request

To create a triage status change request:

1. Open the Findings page.

2. Locate the finding whose status you want to change and click the Status dropdown menu to open a list
of Status options.
3. Select a new triage status.

70
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

4. Enter a comment and click Submit.

Approving a Status Change Request

To approve a triage status change request:

1. Open the Findings page.

2. Use the Pending Status filter to list status change requests.
3. Click the requested status for the finding, then click Approve.

Manual Entry Configuration

The Manual Entry Configuration page allows Software Risk Manager administrators to define custom
values which can be entered into certain fields in the Manual Results.
Click the Settings icon in the navigation bar and select Manual Entry Configuration from the left menu to
open the Manual Entry Configuration page.

71
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This page displays a list of existing detection methods and allowed tools. From here, you can add, delete,
or rename detection methods, and add or remove allowed tools.
For more information on detection methods and allowed tools, see the following topics:

• Managing Detection Methods

• Managing Allowed Tools

Managing Detection Methods

Software Risk Manager provides built-in detection methods, which explains how a finding was discovered.

72
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

These built-in detection methods reflect the types of tools currently supported by Software Risk Manager.
For manual entry, you may wish to specify your own custom detection methods.

Adding a Detection Method

To add a new detection method:

1. Click the Settings icon from the navigation bar and select Manual Entry Config from the left menu.

2. Click Add Detection Method.

73
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Enter a name for the detection method.

4. Click Save.

Renaming a Detection Method

You can rename your custom detection methods as needed. However, the built-in detection methods
cannot be edited in any way (indicated by the lock icon next to their edit/delete buttons).
To rename a detection method:

1. Click the Settings icon from the navigation bar and select Manual Entry Config from the left menu.

74
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the dropdown configuration icon to the right of the detection method and select Rename.

This opens the Rename Detection Method window.

75
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Enter a different name for the detection method.

4. Click Save.

Deleting a Detection Method

You can delete any unused custom detection methods (i.e., as long as no manually entered results use it
as their own detection method). If your custom detection method is in use when you try to delete it, you will
have to choose a replacement. All results using that detection method will be edited to use the
replacement detection method instead. This will likely trigger the recorrelation prompt, since detection
method is one of the correlation criteria.
To delete a detection method:

1. Click the Settings icon from the navigation bar and select Manual Entry Config from the left menu.

76
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the dropdown configuration icon and select Delete.

This opens the Delete Detection Method window.

77
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Click Delete to confirm.

Managing Allowed Tools

The Allowed Tools section lets you define which tools will appear in the Tool dropdown in the Manual
Result form. The names you add to this list do not necessarily need to correspond to a tool known to
Software Risk Manager, or even a real tool, for that matter: you can enter any tool name you want.

Note: Unlike the Detection Methods delete, you don't need to pick a replacement to delete an item in this
list; this list only controls which tools are available when creating a new manual result, not which tools
exist.

Adding an Allowed Tool

To add an allowed tool:

1. Click the Settings icon from the navigation bar and select Manual Entry Config from the left menu.

78
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the Add Allowed Tool button.

3. Enter the name of the tool.

79
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

4. Click Save.

Deleting an Allowed Tool

To delete an allowed tool:

1. Click the Settings icon from the navigation bar and select Manual Entry Config from the left menu.

2. Click the dropdown configuration icon to the right of the allowed tool and select Delete.

80
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This opens the Delete Allowed Tool window.

3. Click Delete to confirm.

Triage Assistant

If machine learning is enabled, Software Risk Manager is capable of automatically (re)training a prediction
model so that it does not have to be done manually. The ML Service Management section will
automatically transition from an Idle state to a Working state when Software Risk Manager automatically
initiates a training session. Whether automatic updates of the prediction model occur at all, and the time at
which they occur, are configurable through the SRM props file (see the Install Guide for more information.)
Click the Settings icon in the navigation bar and select Machine Learning (ML) Control Panel from the top
menu to open the Machine Learning Control Panel page.

There are two parts to the Machine Learning Control Panel:

• Configure Machine Learning for Predicted Status. This part involves switching on the service
management and retraining the prediction model.

81
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Identify projects that may be outliers for the predicted status. This part involves adding exclusions.

Configuring Machine Learning for Predicted Status

Machine learning configuration allows admins to manually trigger the training of the prediction model. To
make use of machine learning, Software Risk Manager requires that at least 100 findings have been
actively triaged. These triaged finding can come from multiple projects. If you have not met this
requirement, then you will be presented with a statement detailing how many findings you have actively
triaged and a statement detailing the minimum requirements.
The ML Service Management section of the control panel transitions back and forth between two states.
The first is an Idle state, which means that Software Risk Manager is not currently training a prediction
model. The second is a Working state, which means that Software Risk Manager is currently training a
prediction model. If the section is in an Idle state, then either a Build Prediction Model button or an Update
Prediction Model button will be present. Specifically, the Build Prediction Model button will be present if a
prediction model has not been trained, and the Update Prediction Model button will be present if a
prediction model has been trained.

When ML Service Management is off, Software Risk Manager will begin training a prediction model when
the Retrain Prediction Model button is clicked. This will transition the section into a On state.
Once training has completed, the section will transition back to an Idle state and will present the user with
when the last training session completed, how long it took, and whether or not it succeeded.

Managing Exclusions
The Excluded Projects section allows admins to configure which projects should not be considered when
Software Risk Manager trains a prediction model. All excluded projects are listed.

Viewing Existing Exclusions

To view an existing exclusion:

1. Click the Settings icon in the navigation bar and select Machine Learning (ML) Control Panel from the
top menu.

82
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Use the search field to search by name or click the column header to re-sort the list.

Adding an Exclusion
Adding exclusions will exclude the selected project from prediction models that Software Risk Manager
trains.
To add an exclusion:

1. Click the Settings icon in the navigation bar and select Machine Learning (ML) Control Panel from the
top menu.

83
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click Add Exclusion.

3. Select from the list of exclusions or use the search field to search by name.
4. Click Add Exclusion.

Removing an Exclusion
You can also choose to re-include an excluded project so that it may be considered during training by
removing it.
To remove an exclusion:

1. Click the Settings icon in the navigation bar and select Machine Learning (ML) Control Panel from the
top menu.

2. Locate the exclusion you want to delete.

You can use search field to search by name or click the column header to re-sort the list.

84
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Click Remove.

Polaris Assist (Beta)

Use the "Polaris Assist (Beta)" tab on the Settings page to configure and enable Polaris Assist. SRM uses
Azure OpenAI APIs, namely the Chat Completion API, and the Azure OpenAI URL must refer to a service
which exposes this endpoint.
Warning: Polaris Assist generates results created by artificial intelligence (AI) or other automated
technologies. Such results are provided for informational purposes only and should not be relied upon for
any specific purpose without verification of its accuracy or completeness.
SRM will use the model gpt-4o in its requests, which requires that a model with that name be available in
the provided API.

Note: The model gpt-4o is the default. To change this model, see Polaris Assist in the Install Guide.

Enter your Azure OpenAI URL and API Key, then click Test Connection. Use the checkbox to enable
Polaris Assist.

85
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The "Test Connection" button will perform a test request using the configured model-id.
For more information on configuring Polaris Assist and AI Insight, please refer to the Install Guide.

Add-In Tools

An add-in tool is based on a scan request file that you define and register with Software Risk Manager. A
scan request file contains the instructions that the tool service needs to invoke an application security
testing tool on a Kubernetes cluster and ingest its output into Software Risk Manager.
The Add-In Tools section appears when the Tool Orchestration Service is enabled. (See Tool Orchestration
in the Software Risk Manager Install Guide for instructions on how to enable this feature.)
Click the Settings icon in the navigation bar and select Add-In Tools from the top menu to open the Add-In
tools page.

The Add-In Tools page allows you to manage the list of application security testing tools that can run on
your cluster.
Add-In tools must be enabled on a per-project basis, and a registered tool starts in a disabled state. See
the Customize Add-In Tools section to learn how to enable a tool for a specific project. You can also use
the Default enabled toggle to enable a tool for every project, excluding those where it was explicitly
disabled. Avoid enabling tools by default when they include project-based settings.
Some add-in tools, such as DAST tools, do not require an analysis input. Software Risk Manager will offer
to run them with each new analysis. Others require an input file, and Software Risk Manager will scan a file
to build a list of tags describing its contents. Tool registration data lets Software Risk Manager select
appropriate add-in tools to run.

86
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Matched Tags section lets you associate content tags with an add-in tool. Select the Tag type and
specify the associated criteria for the content tag. For Language, Runtime, and Meta, select from the
options in the dropdown menu. For Extensions, specify any number of extensions to associate with the
add-in tool as either a comma or space-delimited list (e.g., zip, msi, pkg or just zip). Click Add Tag to
link a tool with a content type.
The Language and Runtime tags are detected based on the presence of files with the appropriate
extension for the language or runtime. The Meta tags are based on the presence of other files:

• OpenSSL. An opensslv.h file

• NuGet Manifest. Any .nuspec file
• npm Package. A package.json file
• .NET Core, Framework, Standard. Any .csproj or .vbproj file (contents are inspected to determine
framework type)

Viewing Existing Add-In Tools

To view existing add-in tools, click the Settings icon in the navigation bar and select Add-In Tools from the
left menu.

This list shows all the existing add-in tools along with information about how many tags have been
assigned and whether the tool has been enabled.

87
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Creating a New Add-In Tool

The Create New Tool feature allows you to add a tool registration.
To create an new add-in tool:

1. Click the Settings icon in the navigation bar and select Add-In Tools from the left menu.

2. Click Create New Tool.

88
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Select a tag type and language from the dropdown list.

4. Add a tag.
5. Enter a TOML Spec in the blank field.
The TOML Spec includes the scan request file content that defines an add-in tool. (See the Scan
Request File section to learn more about scan request files.)
6. Click Done.

Configuring an Add-In Tool

To configure an add-in tool:

1. Click the Settings icon in the navigation bar and select Add-In Tools from the left menu.

89
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the tool's dropdown configuration icon.

90
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Make changes as needed.

4. Click Done.

Renaming an Add-In Tool

You can change the tool's name by editing the window title and clicking OK, but you must click Done to
save a tool name change. Tool names must be unique, and bundled add-in tools cannot be renamed.

Assigning Tags to Findings

Tags are part of a project's metadata, which can be configured by users with a "manage" role. (For more
information, see Configuring Project Metadata.)
Click the Settings icon in the navigation bar and select Tags from the left menu to open the Tags page.

This page lists all tags (alongside the number of findings to which each tag has been assigned) that can be
assigned to findings.
For more information, see the following topics:

• Viewing existing tags

• Adding a tag
• Renaming a tag
• Deleting a tag

91
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Viewing Existing Tags

The Tags page shows a list of existing tags and the number of associated assignments.
To view a list of existing tags:

1. Click the Settings icon in the navigation bar and select Tags from the left menu.

2. Click the column headers to re-sort the list.

Adding a Tag
To add a tag:

1. Click the Settings icon in the navigation bar and select Tags from the left menu.

92
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click Add Tag.

3. Enter a name for the tag.

4. Click Save.

Renaming a Tag

Note: If you attempt to rename a tag to a name that already belongs to a tag that has been assigned to
at least one finding, then you will be prompted with a dialog asking you to confirm the operation. If you
confirm the operation, then the tag will be renamed, and the finding assignments between the involved
tags will be merged. Note that the number of assignments is not necessarily equal to the sum of the
finding assignments between tags once they have been merged, as it is possible for tags to have
overlapping finding assignments. If you do not confirm the operation, then the operation will be cancelled.

To rename a tag:

1. Click the Settings icon in the navigation bar and select Tags from the left menu.

93
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the dropdown configuration icon to the right of the tag name and select Rename.

This opens the Rename Tag window.

3. Enter a new name for the tag.

4. Click Save.

Deleting a Tag

Note: If you attempt to delete a tag which has been assigned to at least one finding, then you will be
prompted with a dialog asking you to confirm the operation. If you confirm the operation, then the tag will
be deleted and, as a consequence, the tag will be unassigned from all findings to which the tag had been

94
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

assigned. If you do not confirm the operation, the operation will be cancelled.

To delete a tag:

1. Click the Settings icon in the navigation bar and select Tags from the left menu.

2. Click the dropdown configuration icon to select Delete.

This opens the Delete Tag window.

3. Click Delete to confirm.

Server Logs

95
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Server Logs page displays the contents of the Web App log, which includes details related to analysis
progress, user changes, issue tracker updates, and warnings and errors. The Web App log can be useful
in troubleshooting issues within Software Risk Manager as well as providing context when creating a
support ticket.
Click the Settings icon in the navigation bar and select Server Logs from the top menu to open the Server
Logs page.

Software Risk Manager maintains additional log files that provide detailed information about runtime
operations for various other tools bundled with Software Risk Manager. These files are located in the log-
files folder in the Software Risk Manager appdata directory.
(For more information about the appdata directory, see "Understanding the AppData Directory" in the
Software Risk Manager Install Guide.)

Viewing and Downloading the Server Log

To view and download the server log file:

1. Click the settings icon in the navigation bar and select Server Logs from the left menu.

96
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Use the Line Wrapping toggle for easier viewing.

2. Click the Download button and select one of the following options:
• Last WebApp Log. Downloads the most current web app log. The WebApp Log is the most
common server log used for troubleshooting.
• All Logs Zipped. Downloads all of the server logs in one .zip file, including all webapp logs,
ML_Triage logs, and logs with supporting data from analyses.

License Information

The License page provides information pertaining to the current SRM license and includes an option for
upgrading your license.
Click the Settings icon in the navigation bar and select License from the left menu to open the License
page.

97
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

In addition to the SRM license ID, the following information is also displayed:

• Current number of active SRM users.

• Number of projects.
• License expiration date.

Click Update License to enter a new license key.

Roles

Roles enable users to interact with SRM in ways permitted by the set of permissions included in their
definition. Role definitions can be viewed, edited, and created on the Roles page.
Click the Settings icon in the navigation bar and select Roles from the left menu to open the Roles page.

98
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This page displays both Global Roles and Project Roles. SRM comes preconfigured with a collection of
built-in roles, each of which is denoted by a padlock symbol next to its name.
Built-in roles can only be viewed, while all other roles can be edited, deleted, and replaced. Only custom
project roles can be created.

View Role
A built-in role's name and its set of associated permissions can be viewed on the Roles page.
To view a role's definition:

1. Click the Settings icon in the navigation bar and select Roles from the left menu.
2. Open the context menu for the role and select the View Role option.

This opens the View Role window.

99
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Review the role's name and its set of associated permissions.

4. Click Done.

Edit Role
A custom project role's name and its associated set of permissions can be edited on the Roles page.
To edit a custom project role's definition:

1. Click the Settings icon in the navigation bar and select Roles from the left menu.
2. Open the context menu for the role and select the Edit Role option.

This opens the 'Edit Role' window.

100
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Review the role's name and set of associated permissions and make changes as necessary.

Note: Role names are unique. An error will be presented in the event that a role's name is changed
to one that already exists.

4. To save the changes made, click Save, otherwise click Cancel to discard them.

Delete Role
Custom project roles can be deleted on the Roles page.
To delete a custom project role:

1. Click the Settings icon in the navigation bar and select Roles from the left menu.
2. Open the context menu for the role and select the Delete Role option.

101
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This opens the Delete Role window.

3. If the role to be deleted has been assigned to users or user groups, a replacement can be selected by
checking the "Reassign all..." checkbox and then selecting a replacement role.

4. To delete the role, click Delete, otherwise click Cancel.

Replace Role Assignments

On the Roles page, users and user groups who have been assigned a role can have their assignment
replaced with a different role.
To reassign users and user groups who have been assigned a role with a different role:

1. Click the Settings icon in the navigation bar and select Roles from the left menu.
2. Open the context menu for the role and select the "Reassign Users and User Groups to Another Role."

Note: The "Reassign Users and User Groups to Another Role" context menu option will be disabled
if the role is not assigned to an users or user groups.

102
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This opens the Replace Role window.

3. Select a replacement role.

4. To reassign users and user groups to the selected replacement role, click Replace, otherwise click
Cancel.

Create Custom Project Roles

Custom project roles can be created on the Roles page.
To create a custom project role:

1. Click the Settings icon in the navigation bar and select Roles from the left menu.
2. Click on the New Custom Role button in the Project Roles section of the Roles page and choose to
base the new role on an existing one or to build the new role from scratch.

This opens the New Custom Role window.

103
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Name the custom role and select any number of permissions.

Note: Role names are unique. An error will be presented in the event that a role is attempted to be
created with a name that already exists.

4. To create the new custom role, click Save, otherwise click Cancel.

For more information on how to assign roles, see the following topics:

• Configuring a User Profile

• Configuring User Group Roles

Project Management Overview

Before you can run an analysis on a file, you need to create a project. Once projects are configured, which
includes policy associations, tool configurations, analysis settings, and so on, you can add files for
analysis. SRM analyzes the files in that project and creates findings that can be viewed on the Findings
page.
When working with projects, it's important to understand the following terms:

104
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Project. A collection of branches for a target software.

• Branch. A unique line of development containing a collection of scans over time. A project contains at
least one branch, and each branch may contain any number of findings.
• Analysis. An individual scan, in which any number of tool results are taken into account in order to
create or update findings.
• Finding. Information about some part of an application, generally a flaw or vulnerability. Findings are
generated from an analysis, but can also be entered manually.
• Tool Result. Information about an application, as reported by a tool; tool results are correlated during
analysis, becoming associated with findings.
• Manual Result. Information about an application which is entered into the system manually.
• Result. A generic term that includes both tool and manual results.

Project Management Tasks

For more information on Project Management tasks, see the following topics:

• Working with Projects

• Using Filters to Find Projects
• Adding a Project
• Working with Nested Projects
• Configuring a Project Analysis
• Configuring Tools for a Project
• Configuring Tool Connectors for a Project
• Analyzing Code in a Git Repository
• Issue Tracker Configuration
• Configuring Project Metadata
• Tool Service Configuration
• Orchestrated Analysis
• Working with Project Branches
• Intelligent Orchestration

Working with Projects

Click the Project icon in the navigation bar to open the Projects page.

105
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Viewing Project Information

The Projects page provides a variety of information and project options, as detailed below.

1. Project name and branch. This includes the project name, child projects, and associated branch. A
paperclip "attachment" icon signifies that the project has linked attachments. (Clicking the icon displays
the Attachments page with its list of attached files.)

2. Analysis information. Shows the current number of findings, when the last analysis was completed,
and how long the analysis took to complete. Click the Findings link to open the project's Findings page.

3. Policy information. This includes an icon next to the project name to indicate policy violation status, a
tally of how many violations in each status category, and how many policies are associated with this
project.

106
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

4. Task options. Click the dropdown configuration icon for a list of configuration options.

Adding an Attachment to a Project

File attachments can be added to a project from the Projects page or the project's Findings page.

Adding an Attachment from the Projects Page

To add an attachment to a project from the Projects page:

1. Click the Project icon in the navigation bar to open the Projects page.
2. Click the dropdown configuration icon for the desired project and select Attachments.
3. Use "drag-and-drop" to add a file or click Add Attachment.
New files will be displayed in the attachment list, which includes the file name, file size, type, who
attached the file, and when the file was added.

107
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

4. Use the dropdown configuration icon to download or delete an attachment.

You can also click the filename to download the attached file. Or, you can download multiple files by
selecting the file checkbox and clicking Download.

Adding an Attachment from the Findings Page

To add an attachment to a project from the project's Findings page:

1. Click the Project icon in the navigation bar to open the Projects page.
2. Locate the desired project and click the Findings link.

3. Select Attachments from the upper menu.

New files will be displayed in the attachment list, which includes the file name, file size, type, who
attached the file, and when the file was added.

4. Use the dropdown configuration icon to download or delete an attachment.

You can also click the filename to download the attached file. Or, you can download multiple files by

108
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

selecting the file checkbox and clicking Download.

Project Configuration Options

Clicking the project's dropdown configuration icon provides the following options:

• Dashboard. Opens the project's analysis dashboard.

• New Analysis. Triggers an analysis.
• Edit Project. Opens an edit window where you can change the project name and parent project
association.
• Create Child Project. Opens a window where you can create a new child project and branch
association.
• Policy Associations. Lists current policy associations and provides options to add or delete policy
associations.
• Analysis Config. Opens the configuration window where you can edit configuration settings.
• Project Metadata. Opens a window where you can add metadata to the project.
• Intelligent Orchestration. Allows you to enable or disable Intelligent Orchestration.
• Git Config. Allows you to enter a Git repository URL and assign a branch association.
• Issue tracker Config. Opens the Issue Tracker Configuration window where you can edit or delete
configuration settings.
• User Roles. Lists current users and their assigned roles and provides options to edit roles according to
project.
• Tool Config. Opens the Tool Configuration page where you can configure appsec tools.
• Tool Connectors. Opens a window where you can add or remove associated tool connectors.
• Configure Tool Service. Opes the Tool Configuration page where you can edit configuration settings.
• View Orchestrated Analyses. Opens the Orchestrated Analyses page where you can view analysis
data.
• Manage Branches. Opens the Manage Branches page where you change branch associations.
• Attachments. Allows you to add attachments (files) to a project.
• Delete Project. Allows you to delete a project.

Using Filters to Find Projects

Filters can make it easier to find a specific project without having to scroll through the entire project list.
Click the Projects icon in the navigation bar to open the Projects page. The Filter field is located at the top
of the page on the right side.

109
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

If the project includes metadata, advanced filters are available by clicking the filter icon next to the Add
Project button.

Filtering Projects
To filter the project list:

1. Click the Projects icon in the navigation bar to open the Projects page.

2. Enter a search term in the filter projects field and the list will filter automatically.
Use the "x" to clear the search field.
3. (For projects including metadata) Click the Filter icon to open the advanced filter options.

110
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

4. Enter search terms in the relevant metadata fields.

The list will sort automatically. Clicking the Filter icon again will close the filter window.

Adding a Project

Before you can run an analysis, you need to create a project.

To add a project:

1. Click the Projects icon in navigation bar to open the Projects page.

2. Click Add Project.

111
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Enter a unique project name.

4. Select or enter the default branch.
For more information on project branches, see Project Branches below.
5. Click Save.

Project Branches
A Branch is a unique line of development containing a collection of scans over time. Each project contains
at least one branch.
New branches can only be created by running an analysis. When creating a new branch for an analysis, a
parent branch needs to be chosen. Conceptually, this represents the development line that this new
branch was forked from. The new branch will be created by cloning the Findings and Results from the
chosen parent branch, and then running the new analysis. The newly created branch will have the same
contents as if the analysis had been run on the parent branch. However, since this is a new branch, the
parent branch will be left untouched, and thus the two branches will be able to be tracked independently of
each other over time.
The Branch Management page is used to manage the branches for a project and is accessible by users
with the manage role.
Click the Projects icon in the navigation bar, then click the project's dropdown configuration icon and select
Manage Branches.

From the Manage Branches page, you can view all branch hierarchies for a project as well as rename and
delete individual branches. To navigate to a project's Branch Management page, click the project's
dropdown configuration icon and select Manage Branches.
When viewing the finding and result information for a branch, a contextualized view of that information is
given. Some information is shared globally across all branches containing the finding, while other
information may differ based on the branch.
Globally shared finding information will be visible on every branch where that finding is present and will not
change based on which branch is being viewed.
Information that is global includes the following:

• Comments added to findings by the user

• Issue Tracker Associations

112
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Tags

Contextual information will be tailored to the selected branch. Contextual information includes the
following:

• Finding Status. Each branch includes a finding status, which includes "new," "existing," and "gone."
• Severity Override. Each branch has its own severity override for each finding.
• Associated Results. Different results may be present on each branch, depending on the analyses
performed.
• Location. Note that line numbers may differ between branches.
• Source Code. Source code mapping will be based on the latest copy of source code uploaded for the
branch.

The Activity Stream will be tailored for the branch that is being viewed and will include the global
information as well as the contextual information (listed above) that is relevant to the branch. Contextual
information is inherited from the parent branch at the time the branch is created. After the analysis for a
new branch begins, any changes to the parent branch will diverge from the new branch and will not be
visible in the child branch.

Project Groups
Projects may be repositioned in a hierarchy, where one project may become the parent (or group)
containing another project.
Once you move one or more projects into a parent project, the parent project can be considered as a
"project group." The Projects page displays project groups as a summary of all findings for all projects in
that group, including the group project itself.

Note: A project group is still a project, and can still have findings of its own. The summary of findings
specific to the parent project will appear above the child projects when you expand the group. There is no
inherent limit to how deeply-nested projects can be. A child project can have its own child projects, and
so on.

Configuring a Project Analysis

Before files can be analyzed, the project needs to be configured for an analysis. Configuration settings
include auto-archiving, hybrid analysis, rule set associations, and so forth.
To configure a project analysis:

1. Click the Project icon in the navigation bar to open the Projects page.
2. Select a project and click the project's dropdown configuration icon and select Analysis Config.
3. Refer to the information below to complete each section.

113
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Analysis Configuration Options

Select general configuration options. General configuration includes the following settings:

• Archive (change status to gone) findings not seen in subsequent tool inputs from the same tool
As files are analyzed with Software Risk Manager, each one is remembered as an analysis input. As
more and more analyses are performed, the number of analysis inputs can become very large. The
Auto-Archival setting controls how old analysis inputs are handled.
By default, auto-archival is enabled. As new inputs are analyzed, old inputs of the same type will be
archived. For example, two analyses are performed in series on a project, both supplying a SpotBugs
results file. In this scenario, the SpotBugs results file provided for the second analysis is perceived as
"newer," so it will replace the SpotBugs results from the first analysis. The analysis input for SpotBugs
results in the first analysis will be archived. Any findings that were present in the first file but not the
second will have their statuses changed to Gone as a part of this process.

114
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

With auto-archival disabled, the two SpotBugs result files will both remain present. This can be useful if
you wish to provide one SpotBugs results file for a part of your application, but a different SpotBugs
results file for a different part of your application. Both files may be analyzed without interfering with
each other. However, keep in mind that without manual management of the analysis inputs, inputs will
begin to pile up, potentially degrading the performance of filters and other interactions. Note: You can
manually archive old inputs from the Analysis Inputs List.
• Allow gone findings to be reopened
If the Allow gone findings to be reopened option is checked, then findings will be reused and have their
status set to Reopened if they reappear later at the same location. With this option disabled, a new
finding will be created instead.
• Reopen resolved findings when updated
If the Reopen resolved findings when updated option is checked, then findings set to a resolved status
(i.e., Ignored, False Positive, Fixed, Mitigated) will have their status changed to Reopened if new data
is brought in from a tool (not matching previously seen data). Findings set to Fixed will be changed to
Reopened if reported, regardless of if the data is new or not (since this signals that the issue has not
been fixed).

Analysis Correlation Options

The correlation options are as follows:

• Prevent tool result correlation

If the Prevent tool result correlation option is checked, then multiple tool results will not be added to a
finding. This will give you a separate finding for every issue reported by a tool. Tool results will still be
associated with rules according to the selected Rule Set; however, when multiple instances of the same
issue occur at the same location, they will not be merged.
• Enable hybrid analysis (causes longer analysis times)
If the Enable hybrid analysis option is checked, then additional steps will be performed during analysis
to enable hybrid analysis. If you upload files that have Java Source or Java Binary files in them,
Software Risk Manager will analyze the structure of these files (gathering information about their
classes and methods), which will later be used to perform hybrid correlation. Note that this extra
analysis is time-consuming; the larger the project, the longer the analysis. Because of this, the Enable
hybrid analysis option is unchecked by default.
• Correlate component results by [mode]

115
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Modes control how Software Component Analysis (SCA) tool results are correlated to findings (for more
information, see Understanding Component Correlation). The options are as follows:
• vulnerability, component name/version, and type
• vulnerability, component identifier, and type
• component identifier and type
• component name/version and type
• vulnerability and type
• Exclude host when correlating infrastructure security-related findings
If the Exclude host option is checked, then host information will be excluded from the correlation criteria
when processing security-related findings. This will produce one finding with tool results from all hosts
for each applicable rule. When this option is not checked, one finding will be produced for each host for
each applicable rule.

Rule Set Associations

The Rule Set Associations section allows you to select the Rule Set that will be used to correlate similar
tool results into Findings.
Three options are available:

• Don't use any rules

• SRM rules
• Clone of SRM rules

By default, new projects will use the built-in "Software Risk Manager Rules" set. The "Don't use any Rules"
option is available if you don't want tool results to be mapped to rules. More information on Rule Sets can
be found in the Rule Sets section of this guide.
Users with the admin role can use this section to manage Rule Sets by creating, cloning, or deleting them.
Click the dropdown configuration icon to open, copy, or delete the Rule Set.
Adding a Rule Set using the Add button will initialize a blank Rule Set.
A cloned Rule Set will be initialized as a copy of the "parent" set. This can be useful if you want one project
to use mostly the same correlation logic, but with a few alterations from another project. Note that the
default Software Risk Manager Rules set is read-only.
To make modifications to a rule set, you need to create a clone first. Click the dropdown configuration icon

116
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

and select Copy to create a clone, then make modifications to the clone.
To view or modify an existing Rule Set, click the dropdown configuration icon and select Open.
Reminder: When making changes in the Analysis Configuration window, make sure to click OK to save
any changes.
Reminder 2: Since a project's configured Rule Set determines the manner in which results are correlated,
changing that configuration necessitates an update of the correlation. This happens when the configured
Rule Set for a project is modified in any way, or if the Analysis Configuration is changed to use a different
Rule Set. When this happens, the Findings page will display a notification prompting users to do so.

Host Scope Associations

Note: This section is only applicable to Software Risk Manager users with the InfraSec add-on.

Host Scopes are sets of projects that share host information with each other. They allow the Host
Normalization process to determine which hosts are actually the same hosts within a Host Scope.
Selecting any of the Host Scopes in the associations list will associate the current project with that Host
Scope, which implies that the current project's host information belongs to the selected Host Scope. Click
the Manage Host Scopes link to open the Hosts page.

Input Content Rules

When a zip-like file (e.g. Zip, Jar, War, etc) is uploaded to a Software Risk Manager project, that project's
Input Content Exclusion Rules and Input Content Identification Rules determine how entries in that zip file
(and possibly entries in other zip-like files nested within the main zip file) will be treated by bundled tools
using that file as input.
Exclusion Rules determine which zip entries will be ignored by bundled tools.
Identification Rules determine the perceived source of the zip entries, as either "library code" or "custom
code" (third-party or first-party, respectively). Many tools will only be interested in custom code, and others
(like component analysis tools) will only be interested in library code.
Proper configuration of these rules can drastically reduce the number of unwanted findings, for example,
by avoiding analyzing files from a third-party library whose code you cannot directly modify.
By default, all entries in a zip-like file will be included, and their role (library code or custom code) will be
automatically guessed by Software Risk Manager.

117
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The two Input Content Rule sections in the Analysis Configuration window share a common format. Each
row represents a rule, where files matching that rule's pattern will be subject to the decision chosen from
its respective dropdown menu. Later rules (further down the list) take precedence over earlier rules. The
first rule will always use ** as its pattern, since it is the fallback for all zip entries. Its pattern may not be
changed, but its decision may be changed. The patterns must be Glob Patterns, e.g., **.java matches
any .java file in any folder. Patterns should use forward slashes (/) to denote directories instead of
backslashes (\), even on Windows.
The / button at the right of the pattern input can be clicked to add a nested pattern that will apply to files
nested in a zip-like file matched by the first pattern. For example, in a project where a .war file is typically
uploaded, you could configure a pattern to match a particular .jar file inside that .war file, then click the
/ button to configure a pattern to match certain .class files inside that particular .jar. To undo adding a
nested pattern, mouse over the > icon to the left of its text input. The icon will become a delete button,
which can be clicked to remove the nested pattern.
To remove an entire rule, click the (-) icon to the right of the rule.

Input Content Exclusion Rules

Exclusion rules can be used to allow tools to completely ignore certain entries in an uploaded zip file. A
typical use-case for this is to avoid analyzing test files. For example, entering src/test/java/**.java
and selecting "Exclude" will exclude all .java files in any subdirectory of the src/test/java directory in
the main zip file. (Note that since there is no leading ** before src, it will only match if the src folder is at
the "top level" of the zip. For example, the pattern won't match a file like other/src/test/java/
Foo.java, but it will match a file like src/test/java/Foo.java.)

Input Content Identification Rules

Identification rules can be used to direct the attention of bundled tools to the correct sections of an
uploaded zip file. For example, many projects will contain a mix of first- and third-party code, and without
insider knowledge, there generally isn't a way for Software Risk Manager to know which is which.
One example of this is when uploading a .war file to be analyzed. The typical internal structure of a .war
file includes many third-party libraries as .jar files, and often the custom code (first-party) is compiled into
another .jar file and placed alongside the third-party .jars. In this case, Software Risk Manager has no
way to distinguish whether each individual .jar file is first- or third-party, so it will typically assume that all
of them are first-party. This can lead to analysis tools becoming overwhelmed and running out of memory
and causing the analysis to fail, or if the tool doesn't fail, it will have produced a large number of

118
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

unactionable results due to it analyzing code from those third-party .jars.

In the example below, a configuration has been made to address a particular case like the one described
above. It starts by assuming any .jarfile is "Library Code", by combining the **.jar pattern with the
Mark as "Library Code" decision. The next rule uses a more specific pattern to match a my-custom-
code.jar and identify it as "Custom Code". This rule overrides the previous one because it comes after.
Next, the user realized that they had some third-party library classes embedded in their "custom code"
.jar file, so they configured a rule to mark those specific files as "Library Code," This was done by first
entering **my-custom-code.jar as the pattern, then clicking the / button to add a nested pattern, then
entering **third-party-content.class as the nested pattern.

Schedule Analyses
You can set your project to schedule an analysis for its Tool Orchestration, Tool Connectors, and Git
configurations. Scheduling intervals include hours and minutes, number of days with a specified time of
day, and number of weeks with a specified day and time. Click the checkbox "Automatically run an
analysis," then use the radio buttons to select how often to run the analysis. Click Save to keep your
settings.

Using Tool Connectors with Analysis Scheduling

This section describes what you should do to have your tool connector(s) included in the analysis.

1. From the Projects page, click a project's dropdown configuration icon and select Tool Connectors.
2. The Tool Connectors window shows your existing tool connectors. Click the add icon (+) for each tool
connector that you want to include in every analysis.
3. Check Run this connector during normal analyses. This will let the tool connector run during an
analysis.

Configuring Tools for a Project

During an analysis, tool results are identified by a tool result type, which is a combination of the tool's
name, any number of "groupings" (e.g., categories), and a name. The Tool Configuration page allows
users with the manage role on a project to enable and disable tool result types for that project. Results
whose tool result types are disabled by configuration will be ignored during an analysis.
Click the Projects icon in the navigation bar to open the Projects page, then click the Project's dropdown

119
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

configuration icon and select Tool Config.

Tool Result Types

Tool result types are organized in a hierarchy, grouped by tool, then category(ies), then name. Tool result
types can be enabled and disabled at any level of their hierarchy by clicking its respective on/off switch.
For example, it is possible to completely disable a tool by clicking the switch next to that tool on the Tool
Configuration page. Some entries will be disabled by default. The default enabled state is carefully
selected to provide optimal results. However, this can be overridden at any time from this page by re-
enabling the desired tool result types. Clicking on an entry (aside from its toggle switch) will expand (or
collapse) it, showing all of its sub-entries.

Note: Any changes made on this page are project-wide, impacting all users of the project.

Software Risk Manager comes with a large set of predefined tool result types, based on the results
generated by a collection of open-source tools. When Software Risk Manager encounters a new type of

120
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

tool result, it will create a corresponding entry based on the result's raw tool code. These entries are
referred to as "observed," and are marked with an eye icon.
If a change to the tool configuration would cause existing tool results to be disabled, it does not
immediately remove those results. Instead a notification will appear, indicating the number of results that
would be affected, prompting the user to purge those results. Clicking the Purge button in the notification
will remove any tool results that still exist despite being disabled. Doing so is highly recommended, as
having fewer tool results will improve the performance and responsiveness of Software Risk Manager. If
you do not purge disabled tool results, they will remain present in the project and will continue to appear in
filters and affect future analyses.

Configuring Tool Connectors for a Project

Tool Connectors allow Software Risk Manager to pull results directly from external tools without manually
exporting the results from those tools and uploading them. Software Risk Manager provides tool
connectors for a variety of app-sec tools. For a complete list, click here.

Note: Users with the manage role need only configure a connection to their tools once.

The Tool Connectors window for a project can be accessed from the project's dropdown configuration icon
on the Projects page.
This window shows any tool connectors that have already been added, along with any tool connectors
configured via central configuration, as well as a list of available tool connectors.

121
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

On a new project, no tool connectors will be configured.

Clicking a link in the bottom section will open a form to configure a connector for the link's respective tool.
Each tool connector configuration form includes a set of fields and tabs, starting with a Config Name field,
which can be anything you choose. (The name won't affect the connector's functionality; it simply identifies
this particular configuration. Since users may configure multiple connectors for a single tool, it may be
useful to choose different names for each connector.)
Configuration tabs and fields are as follows:

• Connection tab
• Tool-Specific Fields. To connect to a tool's API, SRM requires valid credentials for that tool.
Different tools will require different fields; however, typically there will be a URL in combination with
user authentication, such as a username/password combination or API Token.
• Project tab
• Project (or similar). Different tools may use different terminology, such as Build or Application. This
field is used to tell Software Risk Manager which of the tool's projects to pull from. This tab will be
disabled until valid credentials have been entered.
• Version tab

122
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Target SRM Branch. This specifies the name of an SRM branch that the user wants to run analyses
with the selected tool connector.
• Derive version information based on SRM branch name during analysis. This checkbox, when
available, disables other fields from the integration. For example, if there was a "branch" dropdown
from the integration, and you selected this checkbox, the "branch" dropdown would be disabled.
This allows SRM to determine the rest of the configuration based on the SRM branch where you are
running the analysis.
• Fields defined by the integration.
• Options tab
• Available options depend on the specific tool connector.
• Schedule tab
• Auto-update. Selecting Auto-update along with one of the options below it tells Software Risk
Manager to automatically perform an analysis using the configured connector at a regular interval.
Selecting the first option will tell Software Risk Manager to auto-update at a fixed time interval, e.g.,
every 12 hours. Selecting the second option will tell Software Risk Manager to auto-update at a
specified time each day.
• Run this connector during normal analyses. This selection will cause the tool connector to
appear on the New Analysis page as if it were a bundled tool, allowing the tool connector to run
during a normal analysis, alongside any other files you might want to upload for analysis.

Note: Credentials entered for tool connector configurations will be stored (encrypted, but still reversible)
by Software Risk Manager. For added security, it is recommended that users create one-off accounts in a
tool, with the sole purpose of connecting Software Risk Manager to that tool.

Some tools support a "branch" abstraction (though each tool may have its own name for it, such as
"Stream" or "Version"), allowing you to choose different incarnations of a selected project. When supported
by Software Risk Manager, the corresponding field in that tool's connector config form will include a
checkbox that allows you to opt in to sync that tool's "branch" with a corresponding Software Risk Manager
Branch. The sync setting affects the auto-update behavior of the tool connector, as well as setting the
default behavior of the Run Now form when you manually run the tool connector. When enabled, Software
Risk Manager will try to run the tool connector on a Software Risk Manager Branch whose name
corresponds to the selected value in the tool connector configuration dropdown.
Once all of the fields are completed, click OK to save the configuration and return to the connectors list.
Each configured connector has three buttons:

• Run Now. This can be used to start an analysis using a particular tool connector. This process is
independent of the auto-update setting: it can be done regardless of whether or not the connector is
configured to auto-update and will not interrupt the auto-update schedule. Users with the create role
(specifically, the project:manage-tool-connectors and analysis:create permissions) for the
project will be able to interact with this button.
• Edit. This reopens the configuration form for an individual tool connector. Only users with the manage
role will be able to interact with this button.
• Delete. This deletes an individual tool connector. Only users with the manage role (specifically, the
project:manage-tool-connectors permission) will be able to interact with this button.

After clicking Run Now in the list of configured connectors, a form will appear, allowing you to choose the

123
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Software Risk Manager Branch in which the analysis will be run. If you configured one of your tool
connector's fields to sync with a Software Risk Manager Branch, the form will default to the corresponding
branch. If the configured sync target branch does not exist, you must also select a parent branch so that
Software Risk Manager can create a new branch, forked from your selected parent branch, to correspond
with the sync target from your connector configuration. Once you complete the branch selection in the
form, submit it by clicking Run Now. This will initiate a new analysis to run the connector in the
background, close the Tool Connectors dialog, and display a notification.
Qualys VM Tool Connector and Scheduling Auto Update
For more information, see the following sections:

• Qualys VM Tool Connector

• Scheduling Auto Update

Supported Tool Connectors

Tool Connectors allow Software Risk Manager to pull results directly from external tools, without the
manual work of exporting the results from those tools and uploading the results into Software Risk
Manager. Users with the manage role can configure a connection to their tools one time and have
Software Risk Manager take care of the rest.
Software Risk Manager currently provides connectors for the following tools:

• 42Crunch
• Aqua Enterprise
• Acunetix 360
• APIsec
• AWS Security Hub
• Black Duck SCA
• Black Duck Binary Analysis
• Burp Enterprise
• Check Point CloudGuard
• Checkmarx
• Checkmarx One
• Checkmarx-IAST
• Checkmarx OSA
• CodeSonar
• Contrast
• Coverity Connect
• Coverity on Polaris
• Data Theorem Mobile Secure
• DefenseCode ThunderScan
• Dependency-Track
• Dynatrace
• Faraday
• Fortify Software Security Center
• GitHub Advanced Security

124
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: The GitHub Advanced Security tool connector requires the user associated with the access
token to have permission to access the repositories, scopes public_repo for Dependabot and/or
scopes security_events for Code Scanning.

• Hacker One
• HCL AppScan Enterprise
• HCL AppScan on Cloud (ASoC)
• Imperva
• Invicti Enterprise (formerly Netsparker Enterprise)
• IriusRisk
• JFrog Xray

Note: The JFrog Xray tool connector requires the user associated with the access token to have the
"Manage Reports" role.

• Mend
• Microsoft Defender For Cloud
• NeuVector
• NowSecure
• Orca Security

Note: The Orca Security connector requires an API token with the following permissions:
• Authorization - Integration API tokens Read
• Shift Left - CLI (All)
• Shift Left - Scan Logs (All)
• Shift Left - Projects Read

• Prisma Cloud (Redlock)

• Prisma Cloud Compute (Twistlock)
• Polaris
• Q-MAST
• Qualys VM (InfraSec add-on)
• Qualys VMDR
• Qualys WAS
• Rapid7 InsightAppSec

Note: The Rapid7 InsightAppSec tool connector requires the user associated with the access token to
have the "InsightAppSec Admin" role.

• Rapid7 InsightVM
• SD Elements
• Seeker

125
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: The Seeker tool connector requires an API key with "Manage Projects," "View Reports," and
"View Vulnerabilities" permissions.

• Semgrep
• Snyk
• SonarQube/SonarCloud
• Sonatype Nexus
• Black Duck Managed Services Platform
• Tenable.io
• Tenable.sc
• Tenable.io Web App Scanning
• Tinfoil API
• Tinfoil Web
• Trustwave App Scanner
• Veracode
• WhiteHat
• Wiz

Qualys VM Tool Connector

Note: This section is only applicable to Software Risk Manager users with the InfraSec add-on.

The Qualys VM connector has two unique form configurations to choose from. The default form
configuration has customization options including severity types, Asset Group Titles, IP Ranges, and
Include findings last seen field. Include findings last seen is a required field and determines how far back to
consider vulnerabilities that will be pulled into Software Risk Manager. Asset Group Titles and IP Ranges
are optional fields and act as filters. For example, if you provide an IP range, only that information will be
pulled into Software Risk Manager. Additionally, if both fields are left blank, all vulnerability information in
Qualys will be pulled into Software Risk Manager. Multiple IPs can be specified by separating them with a
comma, and IP ranges can be specified by separating them with a hyphen.
To access the second form configuration, select the Import data using a Report Template option. This form
will present you with a Report Template dropdown and Check on report every field. Both fields are required
for this configuration. The Check on report every field determines how often Software Risk Manager will
interface with Qualys to get the status of the report being analyzed. The Report Template dropdown is
populated with report templates that have been configured for your Qualys VM subscription. Software Risk
Manager will request that Qualys generate a report using the selected report template; once the report has
been generated, it will be imported into Software Risk Manager.

126
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Scheduling Auto Update

To set an auto-update schedule for your tool connector:

1. Click the Projects icon in the navigation bar to open the Projects page.
2. Click the Project's dropdown configuration icon and select Tool Connectors.
3. Select a tool connector, then click the dropdown configuration icon and select Edit.

• To choose a daily time to update, select Every day at and fill in the time of day to run the analysis.
• To choose a specific schedule to update, select Every and enter the number of analyses to run and
the time frame (minutes, hours, days).
4. Select Run this connector during normal analyses if you want your tool connector to run during a
scheduled analysis.

127
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: If you configured one of your tool connector's fields to sync with a Software Risk Manager branch
which does not yet exist, the connector will not be able to run. This will be indicated with a warning icon
next to the tool connector's name in the list of configured tool connectors. The appropriate Software Risk
Manager branch can be created by running a normal analysis or by clicking the Run Now button and
submitting the subsequent form. Once the appropriate Software Risk Manager branch has been created,
auto-update can continue.

Analyzing Code in a Git Repository

Software Risk Manager can be used to analyze code stored in a Git repository.

Configuring a Project to Use a Git Repository

To configure a project to use a Git repository:

1. Click the Projects icon in the navigation bar to open the Projects page.
2. Click the project's dropdown configuration icon and select Git Config.
3. Enter the Repository URL and branch name.
4. If the repository requires credentials to access, click Use Credentials and enter the credentials.
5. Click Test Configuration to validate the configuration.
6. Click Ok to save the configuration.
The Git Configuration popup will appear.

The form inside is used to tell Software Risk Manager to use a Git repository as the subject of analysis for
this project. Once configured, Software Risk Manager will automatically include the contents of the
configured repository as an input for each analysis with this project.
The Git Configuration window has two fields: Repository URL and Branch. The Repository URL should be
filled out with the URL that you would use to clone the repository. The Branch field should be filled with the
name of the branch in that repository that you want Software Risk Manager to analyze. By default, the
branch is set to "main", which is the main branch for most Git repositories.
For many projects, setting up a Git configuration is as easy as copying the repository's URL into the text

128
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

field and clicking Test Configuration. For example, if you wanted to analyze the contents of the open-
source WebGoat repository, you would find the clone URL on the side of the GitHub repository page, then
copy it into the Repository URL field in the Git Configuration window.

Software Risk Manager will verify the repository's existence and determine whether it needs credentials to
connect. Click Ok to save and close the form.

Note: For public (open-source) repositories, credentials are not required. However, if credentials are
required, see Working with Git Credentials for more information on how to manage credentials.

Once you have entered a URL and branch, and entered whatever credentials are necessary, click Ok to
save the configuration. Doing so will close the window and tell Software Risk Manager to obtain a local
clone of the configured repository. Depending on the size of the repository, the length of its history, and
your network connection, the clone operation may take anywhere from seconds to hours. Once started, a
progress bar will be displayed underneath the project's title on the Projects page.

129
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The "cloning" job has several subtasks, so you will see the progress bar fill up several times. When the job
is complete, the progress bar will turn blue, remain for a couple of seconds, then slide out of view.
Once the clone is ready, the New Analysis page will automatically include the latest contents of the
configured branch of the configured repository as an input. See the Analysis Overview section for more
detail.

Working with Git Credentials

Some Git repositories are private and require credentials for access. Software Risk Manager supports two
forms of authentication: HTTP and SSH. Depending on the URL in the Repository URL field, Software Risk
Manager will automatically determine which type of credentials are required.
If you try to test the configuration for a private repository without entering credentials, Software Risk
Manager will automatically enable Use Credentials and require that they are entered. Similarly, if
credentials are provided when configuring a public repository, Software Risk Manager will automatically
disable Use Credentials.

HTTP Credentials
HTTP credentials consist of a username and password. For GitHub repositories, these will generally be
your GitHub account name and password. GitHub also supports creating "Personal access tokens," which
can be used in place of a password.

SSH Credentials
SSH uses a pair of files known together as a "keypair," or separately as a "private key" and "public key."
For Software Risk Manager to connect to a repository through SSH, it needs your private key. The system
in charge of the repository's security will also need your public key.
If you are trying to access a private GitHub repository, visit your SSH Keys page at https://github.com/
settings/ssh to register your SSH key with GitHub. GitHub also provides help with SSH-related issues at
https://help.github.com/categories/ssh/.
Some users will already have an SSH keypair on their computer. The two files are generally located in
<userhome>/.ssh/ and will be named id_rsa for the private key and id_rsa.pub for the public key. It
is possible to use this pair, but you may want to generate a separate pair for use with Software Risk

130
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Manager.
Once you have located or generated a keypair, copy the contents of the private key file into the Private Key
field.

When generating a keypair, you have the option to provide a passphrase for the private key. If you do this,
Software Risk Manager will need that passphrase to use your private key. Enter it in the Key Passphrase
field.

Two-Factor Authentication with GitHub

If you need to connect to a GitHub repository, and your GitHub account has two-factor authentication set
up, you cannot use your regular username and password to authenticate. To connect over HTTP (e.g.,
https://github.com/user/repo), you will have to set up a Personal Access Token and use it in
place of your regular password. You can still connect over SSH (e.g., [email protected]:user/
repo.git) as usual.

Issue Tracker Configuration

Software Risk Manager allows you to associate findings with issues or work items in an issue tracker,
either by creating a new issue or work item, or by identifying an existing issue or work item.
Software Risk Manager currently supports the following issue trackers:

• Azure DevOps (requires "Read" permission for "Graph" and "Project & Team" scopes, and "Read,
Write, Manage" permissions for "Work Items" scope)
• GitLab (requires "api" access token scope)
• Jira (requires "Browse projects" project permission, "issue-level security" permission if issue-level
security is configured, and the "read:jira-work" OAuth scope if using OAuth)
• ServiceNow
• GitHub and GitHub Enterprise (requires "repo" access token scope)

131
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Configuring an Issue Tracker

To configure an Issue Tracker for a project:

1. Click the Projects icon in the navigation bar to open the Projects page.
2. Click the project's dropdown configuration icon and select Issue Tracker Config.

3. Enter the URL for your Issue Tracker server (including the "http://" or "https://"—even if you're using an
IP address) as well as the credentials required for the user in whose name the issues or work items
will be created.
4. Click Verify.
Software Risk Manager will connect with the server and retrieve a list of projects the user can access.
5. Select the project you want to use from the dropdown menu.
Software Risk Manager will periodically query the issue tracker server to refresh the status for all of the
issues or work items associated with a given project. The Refresh Interval specifies the number of
minutes between refreshes (the default is 60 minutes).

132
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

6. Click OK to save your configuration.

If you delete the issue tracker configuration for a given project, all of the issue or work item
associations tied to the findings in that project will be deleted. However, none of the issues or work
items on the issue tracker server itself will be affected.

Additional Configuration Options

To perform additional configuration options, see the following sections:

• Advanced Field Configuration

• Issue Tracker Two-Way Sync
• Automatic Status Updating
• Automatic Issue Creation

Advanced Field Configuration

When creating an issue or work item from Software Risk Manager, several standard fields are provided
(e.g., summary, description). However, many issue trackers provide more than just a few fields for issues
or work items and can be configured to require these additional fields when creating an issue or work item.
Issue trackers can also allow the creation of custom fields on a per-project or per-server basis. Software
Risk Manager provides for this situation through "Advanced Fields." Jira users should note that while
Software Risk Manager supports all of Jira's "Standard" custom fields as well as many of Jira's "Advanced"
custom fields, some are implemented via third-party plugins and are not fully supported. These fields will
still appear and can be used if the correct format is known, but they should be left empty otherwise.
You can create template expressions for any of the available fields when creating an issue or work item for
the configured issue tracker server. These expressions will be applied to the relevant Software Risk
Manager finding (or findings) when you create an issue or work item, which allows Software Risk Manager
to pre-populate the field with data from the finding, according to your specification. More technical users
should be advised that the template language is the JavaScript Handlebars library and that all of the
template expressions are Handlebars Expressions.
Software Risk Manager will use its own default values for the Summary (Jira), Title (Azure DevOps,
GitLab), Short Description (ServiceNow), Description and Due Date (Azure DevOps, GitLab, Jira,
ServiceNow) fields if none are specified.

Note: Users should note that by default, the Due Date fields are based on the Software Risk Manager
finding Fix By Date. The finding Fix By Date value is just a date; some issue trackers like Azure DevOps
and ServiceNow also expect a time component in the Due Date value. So, SRM sends its local midnight
as the time component value for these trackers, which may be rendered differently on the respective UI
depending on the instance's timezone settings.

Users should also note that because fields can be given template expressions, which won't be evaluated
until a finding is available, the validation that can be done on the fields is limited. The issue tracker field
mappings are an advanced feature, and it is up to the user to make sure that the default values and
expressions entered will produce valid values for the relevant issue tracker field types.

133
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information on field configuration, see the following topics:

• Expression Basics
• Expression Logic
• Helpers
• Enumerable Fields

Expression Basics

The template engine will use the text you provide as-is, but it will treat anything inside pairs of double
braces {{ }} as an expression to be evaluated using the active finding or findings. Software Risk Manager
defines five basic data objects that can be used in the template expressions:

• allFindings - An array of all of the active findings ordered first by the severity then by finding ID.
• finding - The first element in allFindings (i.e., for multiple-finding issues, this will be the finding
with the highest severity and lowest finding ID); this field is most useful for single-finding issues.
• common - An abstract finding containing any field whose value is shared by all of the findings in
allFindings, containing the same fields enumerated below for finding objects; any value not shared
by all findings will be reported as null.
• project - An object containing information about the project.
• trackerType - The type of issue tracker that the template is being generated for ("jira", "azure",
"servicenow", or "gitlab").

These objects can be used to construct expressions containing data from the active findings. For example,

Finding {{finding.id}} has {{finding.severity.name}} severity

will, when applied to a Software Risk Manager finding with ID 1 and High severity, produce the following
text:

Finding 1 has High severity

Code Block Format

Each issue tracker has its own markup language and may require special syntax when you create pre-
formatted code blocks.
Jira: Use {code} before and after the code block.

{code} {{{requestBody}}} {code}

{code} {{{responseBody}}} {code}

ServiceNow: Use [code]<code> before the code block and </code>[/code] after the code block.

134
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

[code]<code> {{{requestBody}}} </code>[/code]

[code]<code> {{{responseBody}}} </code>[/code]

Azure DevOps and GitLab (triple backticks): Use ``` before and after the code block.

```
{{{requestBody}}}
```
```
{{{responseBody}}}
```

Finding Objects
The following fields are available on all finding objects (each element in the allFindings array, finding, and
common). Fields marked as being optional can be omitted or set to null, all other fields will be present. The
only exception to this rule is the common object, where any value not shared by all findings will be set to
null regardless of whether it is optional or not.

• id - The ID of the Software Risk Manager Finding.

• link - A fully qualified URL pointing to the Software Risk Manager details page for this finding; must be
wrapped to prevent html-escaping, for example {{{finding.link}}}.
• triageStatus - The finding's Triage Status, e.g. "Fixed" or "Ignored".
• findingStatus - The finding's Finding Status, e.g. "New" or "Existing".
• assignee - The name of the user that is assigned to the finding
• firstSeenOn - The date the finding was first seen, as text in MM/dd/yyyy format.
• firstSeenOnDate - The date the finding was first seen in ISO 8601 extended format; suitable for use
with the {{formatDate}} and {{formatDateTime}} template helpers.
• triageTime - The date and time the finding's triage status was updated in ISO 8601 extended format;
suitable for use with the {{formatDate}} and {{formatDateTime}} template helpers.
• closeTime - The date and time the finding's triage status was set to a closed status (i.e., Ignored,
False Positive, Fixed, Mitigated, or Gone), in ISO 8601 extended format; suitable for use with the
{{formatDate}} and {{formatDateTime}} template helpers.
• fixByDate - The Fix By Date of the finding in yyyy-MM-dd format.
• detectionMethod - An object representing the manner in which the finding was discovered.
• id - An identifier for the detection method.
• name - The name of the detection method (e.g. "Static Analysis").

135
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• detection - A helper object containing booleans for some pre-defined detection methods.
• isDast - True if the finding is a DAST finding.
• isSast - True if the finding is a SAST finding.
• isComponent - True if the finding is a Component Analysis finding.
• isHybrid - True if the finding is a Hybrid finding.
• isInteractive - True if the finding is an IAST finding.
• isThreatModel - True if the finding is a Threat Modeling finding.
• isNetwork - True if the finding is a Network Security finding.
• isDatabase - True if the finding is a Database Analysis finding.
• isContainer - True if the finding is a Container Analysis finding.
• isCloudInfrastructure - True if the finding is a Cloud Infrastructure Analysis finding.
• detectedBy - The list of tools that detected the finding, in text form.
• descriptor - An object describing the type of finding.
• id - An identifier for the descriptor.
• code - A unique identifier for the descriptor.
• name - A human-friendly name for the descriptor.
• type - The type of descriptor; possible values can include the following:
• rule - This finding represents one or more results that matched a rule in the current Rule Set.
• tool-code / observed-tool-code - This finding directly represents a result from a tool.
• manual-entry - This finding was manually entered.
• cve-group - This finding was created to represent a group of CVEs.
• hierarchy - The hierarchy of the type of finding, corresponding with the nesting represented in the
Type filter on the Findings page; this is an array of strings, with name as the last element.
• cwe - An optional object representing the CWE associated with the finding.
• id - The CWE ID associated with the finding.
• name - The name of the CWE.
• location - The location where the finding has been identified.
• lines - An object representing the line number range on which the finding is present, if available;
uses the format {start: <Number>, end: <Number>}.
• line - The line number of the location, if available, in text form (e.g., '3-5' or '100').
• columns - An object representing the start and end columns of the finding's location, if available;
uses the format {start: <Number>, end: <Number>}.
• column - The column number of the location, if available (e.g., '12-44' or '440').
• path - An object representing the location's path:

136
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• path - The full path of the location.

• pathType - The type of the path (e.g., url or file).
• shortName - A shortened version of path; this is the value that is displayed on the findings
table for the finding.
• hasSource - A boolean value reflecting whether Software Risk Manager has a source file for the
given location.
• element - An optional object representing the element impacted by the finding:
• name - The name of the element.
• shortName - An abbreviated version of the name.
• type - The type of the element.
• keyword - A computer-friendly description of the element type (e.g., "query-string" or "http-
header").
• name - A human-friendly description of the element type (e.g., "Query String" or "HTTP Header").
• severity - An object representing the effective Software Risk Manager severity value for the finding
(severityOverride if specified, otherwise severityDefault):
• key - A numeric representation of the severity; higher is more severe.
• name - The name of the severity (e.g., "Critical" or "Info").
• severityDefault - An object (in the same format as severity above) representing the severity of
the finding as calculated by Software Risk Manager; this is the severity that is used if an override is not
specified.
• severityOverride - An optional object (in the same format as severity above) representing the
user-specified severity override for the finding, if provided.
• descriptions - An object containing the general and contextual descriptions for the finding:
• general - The general description for the finding; corresponds to the description shown at the top
of the Details page.
• format - An indication of the description's format (e.g., 'text', 'markdown', or 'html').
• content - The content of the description in the specified format.
• contextual - The contextual description for the finding, if one is specified; this is in the same
format as the general description above.
• metadata - An object containing metadata available for the finding; each key in the object is the
metadata field name, and the value is the value for that field.
• trainingLink - A fully qualified URL pointing to a Secure Code Warrior training module if available.
NOTE: you are required to wrap this field in an extra pair of curly braces to prevent html escaping of the
URL ({{{trainingLink}}}, for example).
• mostRecentAnalysis - An object representing the last successfully completed analysis that either
generated or updated the finding.
• id - The ID of the analysis.

137
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• projectId - The ID of the Software Risk Manager Project this finding is on.
• state - The state of the analysis, can be one of: Created, Queued, Running, Failed,
Complete.
• createdBy - The object representing the user who created the analysis.
• id - The ID of the user.
• name - The name of the user.
• creationTime - When an analysis was created.
• startTime - When an analysis started.
• endTime - When an analysis ended.
• name - The name of the analysis (note that this value is blank by default unless explicitly set).
• sourceSnippet - An object representing a snippet of code the finding occurs in.
• lines - A list that contains the lines of source code for the snippet.
• startLine - The line number from the source file corresponding with the first element of the list.
• branch - An object containing information about the branch the issue is associated with.
• id - The id of the Software Risk Manager branch.
• name - The name of the Software Risk Manager branch.
• branches - An array containing the branches this finding appears on.
• results - An array of all of the results (ingested from tools and manually entered) on the finding,
corresponding with the Evidence section of the details page, ordered first by the severity and then by
result ID. Each entry contains:
• id - The ID of the Software Risk Manager Result.
• firstSeenOn - The date the result was first seen in ISO 8601 extended format; suitable for use
with the {{formatDate}} and {{formatDateTime}} template helpers.
• isManual - A boolean indicating if the result was manually entered.
• detectionMethod - An object representing the result's detection method (in the same format as
the Finding detectionMethod above).
• tool - An optional string representing the tool name (always present for tool results, but optional for
manual results).
• severity - An object representing the result's reported severity (in the same format as the Finding
severity above).
• cwe - An optional object representing the result's reported CWE (in the same format as the Finding
cwe above); note that the result's cwe may be different from the finding's cwe, due to correlation
based on rule sets.
• descriptor - An object describing the type of result (in the same format as the Finding
descriptor above).
• location - An optional object representing the raw location reported by the result:

138
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• rawDisplayPath - The full display path, as reported by the tool; this will be null for manually
entered results.
• pathObject - An object representing the result's reported path (in the same format as the
Finding location.path above); this path represents the normalized version of the path as
understood by Software Risk Manager, and therefore may be slightly different from
rawDisplayPath.
• lines - An optional { start: <Number>, end: <Number> } object for the result's
reported line numbers, if specified.
• columns - An optional { start: <Number>, end: <Number> } object for the result's
reported column numbers, if specified.
• descriptions - An object containing the general and contextual descriptions for the result.
• general - A description object describing general information about the result (in the same
format as the Finding description objects above).
• contextual - A description object containing specific contextual data reported by the tool or
manual entry (in same format as the Finding description objects above).
• metadata - An object containing tool-specific metadata; keys in this object are a camel case
version of the name shown in the Evidence section of the details page - some (non-exhaustive)
examples are as follows:
• cvssV3 - The CVSS V3 score (typically for component analysis results).
• cpe - The CPE of the associated component (typically for component analysis results).
• veracodeFlawId - The Veracode Flaw ID (for Veracode tool results).
• whitehatVulnerabilityId - The WhiteHat Vulnerability ID (for WhiteHat tool results).
• sonatypeThreatLevel The Sonatype Threat Level (for Sonatype tool results).
• prismaCloudComputeTwistlockDistro The distro of the image scanned (for Prisma Cloud
Compute [Twistlock] results).
• httpMetadata - An object containing the values associated with the result's HTTP Activity;
similarly to metadata, the keys in this object are camel case and corresponds with the values
displayed in the Metadata section for each HTTP variant on each associated result - for example:
• whitehatSentinelAttackVectorId - ["123", "456", "789"] for a result with three
WhiteHat Sentinel Attack Vectors with the IDs 123, 456, and 789.
• cves - An array of CVEs associated with the finding, in text form (each element in the array is a
string in the format CVE-YYYY-NNNN).
• vulnerabilities - An array of vulnerability IDs (e.g., CVE and BDSA) associated with the
finding, in text form (each element in the array is a string in the vulnerability format, such as BDSA-
YYYY-NNNN for BDSAs and CVE-YYYY-NNNN for CVEs).
• variants - An object containing the values associated with the result's request & response HTTP
Activity.
• requestData - Formatted info for an HTTP request as seen in the "Raw Request Data" for a
Result (does not include request body).

139
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• responseData - Formatted info for an HTTP response as seen in the "Raw Response Data" for
a Result (does not include response body).
• requestBody - The body of the corresponding HTTP request.
• responseBody - The body of the corresponding HTTP response.
• hostInfo - An object containing the values associated with the result's Host Info.
• formattedHostname - A formatted list of Host Names.
• formattedFqdn - A formatted list of FQDN.
• formattedIp - A formatted list of IP Addresses.
• formattedMac - A formatted list of MAC Addresses.
• formattedNetBios - A formatted list of NetBIOS Names.
• formattedOs - A formatted list of Operating Systems.
• formattedPorts - A formatted list of Ports in the form of [Port][Protocol][State].
• formattedEnvironment - A formatted list of Environments.
• formattedHostInfo - Full formatted Host Info using all previously listed items.

Project Object
• id - The ID of the Software Risk Manager Project.
• name - The name of the project.
• metadata - An array of value objects entered via the Project Metadata dialog.
• name - The name of the metadata field.
• value - The value entered for the field.
• valueId - For "dropdown" fields, the choice ID.

Expression Logic

Most Handlebars expressions can be used. Some basic examples are given here, but much more
information is available in the Handlebars documentation. Specific sections of interest are Expressions,
Block Helpers, and Built-in Helpers.

Boolean Expressions
You can add basic boolean logic to your expressions by using the helpers if, ifeq, and ifneq. Note that
ifeq and ifneq are custom helpers provided by Software Risk Manager.

• If

140
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

{{#if finding.detection.isDast}}
This finding is a DAST finding.
{{else}}
This finding is not a DAST finding.
{{/if}}

will result

This finding is a DAST finding.

when

This finding is not a DAST finding.

• ifeq
The ifeq helper allows you to test the equality between two string or number values for a boolean
result. Comparing values of types other than strings or numbers is unsupported, and the block will
always evaluate to false.
Note that else can not be used with ifeq; you may use ifneq instead to simulate else.

{{#ifeq finding.statusName "New"}}

This finding is new
{{/ifeq}}

will result in

This finding is new.

when a finding's status is new.

• ifneq
The ifneq helper behaves the same way as ifeq except it negates the boolean result of testing the
equality between two string or number values.

{{#ifeq finding.severity.name "Critical"}}

This finding is critical
{{/ifeq}}

141
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

{{#ifneq finding.severity.name "Critical"}}

This finding is not critical
{{/ifneq}}

will result in

This finding is not critical.

when a finding's severity is not Critical.

Iterating Lists
You can iterate over arrays by using the each helper.
For example, the expression

{{#each allFindings}}
{{id}},
{{/each}}

will result in

1, 2, 3, 4,

when evaluated on a group of findings with the IDs of 1, 2, 3, and 4.

In this example, all Results of relevant Findings are iterated through and all formatted Host Info and Variant
Request and Response data is returned

{{#each allFindings}}
{{#each results}}
{{{hostInfo.formattedHostInfo}}}
{{#each variants}}
Request:
{{{request-data}}}
Response:
{{{response-data}}}
{{/each}}

142
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

{{/each}}
{{/each}}

Understanding and utilizing {{#each}} is important, because as you can see in the above summary of
the properties of the finding objects, many of the properties are arrays and therefore can't simply be
accessed directly—you need to iterate over them and access each property inside the loop.

Helpers

Software Risk Manager includes all the #if, #unless, #each, and #with helpers provided by Handlebars.
Several other helpers are also provided to assist as well.

formatDate

Note: It is recommended to use the new formatDateTime helper which gives you more flexibility to
define both custom input and output format strings.

The formatDate helper allows you to format a date by specifying a format string. For example:
{{formatDate finding.firstSeenOnDate 'YYYY-MM-DD'}}
will take the first-seen date for the finding and convert it into an ISO-8601 valid format. You can use the
symbols below to create your format string:

• M month: 1, 2, 11, etc.

• MM month: 01, 02, etc.
• MMM month: Jan, Feb, etc.
• MMMM full month name
• D day of month: 1, 2, 11, etc.
• DD day of month: 01, 02, 11, etc.
• ddd day of week: Sun, Mon, etc.
• dddd day of week: Sunday, Monday, etc.
• YY year: 98, 99, 00, 01, etc.
• YYYY year: 1998, 1999, 2000, 2001, etc.

The formatDate helper uses Moment.js under the hood, so you can look at its documentation for more
formatting symbols.

formatDateTime
The formatDateTime helper allows you to format a datetime by converting it from a specified input
format to a specified output format. For example:

143
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

{{formatDateTime finding.firstSeenOnDate 'YYYY-MM-DD' 'MM/DD/YYYY'}}

will take the first-seen date for the finding and convert it into the specified output format. You can use the
symbols below to create your format strings:

• M month: 1, 2, 11, etc.

• MM month: 01, 02, etc.
• MMM month: Jan, Feb, etc.
• MMMM full month name
• D day of month: 1, 2, 11, etc.
• DD day of month: 01, 02, 11, etc.
• YY year: 98, 99, 00, 01, etc.
• YYYY year: 1998, 1999, 2000, 2001, etc.
• H hour of day: 1, 2, 11, 21, etc.
• HH hour of day: 01, 02, etc.
• h clock hour of AM/PM: 1, 2, 11, 12, etc.
• hh clock hour of AM/PM: 01, 02, 11, 12, etc.
• m minute of hour: 1, 2, 11, 31, etc.
• mm minute of hour: 01, 02, 11, 31, etc.
• s second of minute: 1, 11, 21, 51, etc.
• ss second of minute: 01, 11, 21, 51, etc.
• S fraction of second: 1, 11, 211, 351, etc.
• SS fraction of second: 01, 11, 211, 351, etc.
• a AM/PM of day: AM, PM
• z timezone name: GMT, EST, PST, etc.

The formatDateTime helper uses java.time under the hood, so you can look at its documentation for
more formatting symbols.

makeOxfordList
The makeOxfordList helper assists in generating an Oxford list from an array of elements. The body will
be evaluated for every item in the list.
For example, to list all of the Software Risk Manager Finding IDs, the template

{{#makeOxfordList allFindings ',' 'and'}}{{this.id}}{{/makeOxfordList}}

will result in

39955, 39956, 39939, and 39940

when evaluated on a group of findings with the IDs 39955, 39956, 39939, and 39940.

formatLocation
The formatLocation helper formats a location object into a user-readable version similar to those

144
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

displayed elsewhere in Software Risk Manager.

For example, the template

{{formatLocation finding.location}}

will result in

AbstractLesson.java:182

when evaluated on a finding located in WEB-INF/classes/org/owasp/webgoat/lessons/

AbstractLesson.java on line 182 (columns 25-50).
By default, the short name of the location is used, and any column numbers are omitted. You may opt to
show the complete location information by passing true as the second parameter to this helper. For
example, the template

{{formatLocation finding.location true}}

will result in

WEB-INF/classes/org/owasp/webgoat/lessons/AbstractLesson.java:182:25-50

in the previous example.

formatCWE
The formatCWE helper creates a more informative representation of a finding's CWE (if one is available).

Note: When using this helper, the last two parameters are optional.

The true/false parameter determines if a link to MITRE will be available. The trackerType parameter will
default to the issue tracker type currently being processed.
For example,

{{formatCWE finding.cwe true trackerType}}

will result in

CWE 78 - Improper Neutralization of Special Elements used in an OS Command ('O

S Command Injection') ([MITRE|https://cwe.mitre.org/data/definitions/78.html])

when evaluated on a finding associated with CWE-78.

If the second argument provided is true, a MITRE link for the CWE will be included (formatted properly for
the issue tracker being used).
If no CWE is present on the finding, this helper will evaluate to an empty string if the second argument is

145
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

false, or to "No Common Weakness Enumeration information available" if the second argument is true.

stripHtmlMarkup
The stripHtmlMarkup helper takes an HTML string and returns a copy with all HTML tags removed,
with newlines/spaces inserted as necessary while attempting to preserve native formatting. By default,
HTML escape sequences will be converted in the result; use false for the second parameter (as seen
below) instead to prevent this. Whitespace-equivalent escape sequences (e.g., &nbsp;) will simply be
replaced with a space regardless of the second parameter value.
For example, a finding with a description of the following

<h1>Explanation</h1>
<p>
Cross-site scripting vulnerabilities occur when:
<ol>
<li>Data enters through an untrusted source</li>
<li>The data is included in dynamic content without being va
lidated for malicious code</li>
</ol>
</p>

and a template with

{{{stripHtmlMarkup finding.descriptions.general.content true}}}

will result in

Explanation
Cross-site scripting vulnerabilities occur when:

- Data enters through an untrusted source

- The data is included in dynamic content without being validated for malici
ous code

The following are known issues and limitations:

• Ordered/unordered lists will produce the same - prefix on list items.

• Nested lists may be improperly formatted.
• Issue trackers that interpret plaintext as emojis (e.g., :() (e.g., Jira) will still interpret as emojis.

146
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• The un-escaped HTML content may be re-converted to the escape sequences automatically by
Handlebars. (e.g., HTML content with &amp;is un-escaped to & by stripHtmlMarkup, but gets
converted back to &amp; in the output by Handlebars.) Use {{{}}} instead of {{}} to prevent this
behavior.

makeMarkupFromHtml
The makeMarkupFromHtml helper takes an HTML string and reformats it into appropriate markup for the
current issue tracker. The helper uses the following formats:

• Jira. Atlassian Wiki markup format.

• Azure DevOps. No processing/pass-through (HTML content supported by ADO).
• ServiceNow. Simple text extraction, acts as an alias for stripHtmlMarkup with unescaping enabled.
• GitLab. Markdown.

The helper takes three arguments: the first is required and the following two are optional: the HTML to
convert and the name of the issue tracker type to target (use trackerType if not manually overriding;
accepted values are jira, azure, servicenow, and gitlab), and a boolean flag (true/false),
indicating whether to pre-clean the HTML of any non-textual elements (defaults to false). The pre-
cleaning flag is usually not necessary, but if there are formatting issues, the pre-cleaning option may
prevent these issues.
For example, a finding with a description of

<h1>Explanation</h1>
<p>
Cross-site scripting vulnerabilities occur when:
<ol>
<li>Data enters through an untrusted source</li>
</ol>
</p>

and a template with

{{{makeMarkupFromHtml finding.descriptions.general.content trackerType}}}

will approximately result in

(If configured tracker is Jira or using `jira` as the second argument value)
h1. Explanation

147
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Cross-site scripting vulnerabilities occur when:

# Data enters through an untrusted source

(If configured tracker is Azure DevOps or using `azure` as the second argume
nt value)
<h1>Explanation</h1><p>Cross-site scripting vulnerabilities occur when: <o
l><li>Data enters through an untrusted source</li></ol></p>

(If configured tracker is ServiceNow, or using `servicenow` as the second ar

gument value)
Explanation
Cross-site scripting vulnerabilities occur when:

- Data enters through an untrusted source

(If configured tracker is GitLab, or using `gitlab` as the second argument v

alue)
# Explanation

Cross-site scripting vulnerabilities occur when:

1. Data enters through an untrusted source

Keep in mind that the use of {{}} vs {{{}}} will affect how Handlebars escapes any HTML-like
content—typically, the {{{}}} literal format is appropriate.
The following are known issues and limitations:

• Jira/Atlassian conversion ignores <pre> code blocks (limitation of Atlassian Renderer).

• Super/sub-scripts are generally unsupported (Jira/Atlassian renderer supports it but has known bugs).
• Nested lists in any format may be improperly formatted.
• Issue trackers that interpret plaintext as emojis (e.g., :() (e.g., Jira) will still interpret as emojis.
• Issue trackers whose formatting is whitespace-sensitive (i.e., Jira, GitLab) may have formatting issues
due to trailing/leading whitespace (the use of ~ for whitespace control is recommended).

148
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

jiraMarkupFromMd
The jiraMarkupFromMd helper is intended to be used to translate descriptions formatted using
markdown into Jira markup.
For example,

{{{jiraMarkupFromMd descriptions.contextual.content}}}

will transform the following description:

# Header

Here is a *description*

1. Number one
2. Number two
3. Number three

into:

h1. Header

Here is a _description_

# Number one
# Number two
# Number three

makeSource Snippet
The makeSourceSnippet helper takes the finding.sourceSnippet object and outputs a formatted
source snippet.
For example,

{{makeSourceSnippet finding.sourceSnippet}}

will result in

149
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

function foo() {
console.log('bar');
}

The following are known issues and limitations:

• Jira/Atlassian shows line numbers, but by default do not support configuring the line numbers. The line
numbers will start at 1.
• Jira/Atlassian has an issue with preserving the first source line's level of indentation.
• GitLab, Azure, and ServiceNow do not show line numbers.
• Service now only supports code blocks in specific fields, like the Additional Comments field.

minBy and maxBy

The minBy and maxBy helpers will cause the provided expression body to be evaluated against the object
with the lowest or highest value. The path to this value is provided as an argument.
For example,

{{#minBy allFindings "severity.key"}}

The lowest severity is on finding {{id}} with severity of {{severit
y.name}}.
{{/minBy}}

will result in

The lowest severity is on finding 10 with severity of Info.

when evaluated on a group of findings, where the lowest severity finding has the ID of 10 and severity of
info.
In the case of a tie (e.g., multiple findings or results with the minimum or maximum value), the first item
with that value will be used. As outlined in Finding Objects, in the case of a tie, this will give the finding or
result with the highest severity and lowest numeric ID.

minByDate and maxByDate

The minByDate and maxByDate helpers will cause the provided expression body to be evaluated against
the object with the lowest or highest date value in yyyy-MM-dd format. The path to this value is provided
as an argument.
For example,

150
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

{{#minByDate allFindings "fixByDate"}}

The lowest date is on finding {{id}}.
{{/minBy}}

will result in

The lowest date is on finding 10.

when evaluated on a group of findings, where the lowest Fix By Date finding has the ID of 10.
In the case of a tie (e.g., multiple findings or results with the minimum or maximum date), the first item with
that value will be used.

Nested Arrays
These helpers can also handle nested arrays in a more advanced use case. This is signified by adding a
.[] at any point the helper should continue iterating over inner arrays. The expression body's context will
be at the inner-most object, and the parent object(s) may be referenced if desired.
Here are two examples to illustrate these points:

{{#maxBy allFindings "results.[].severity.key"}}

Finding {{../../id}}, Result {{descriptor.name}}, Severity {{severit
y.name}}
{{/maxBy}}

will result in

Finding 10, Result My Weakness, Severity Medium

when evaluated against a group of one or more findings where the highest severity result across all of the
findings is a result on finding 10, with a descriptor name of "My Weakness" and medium severity.

{{#maxBy allFindings "results.[].metadata.cvssV3"}}{{metadata.cvssV3}}{{/max

By}}

will result in

9.8

when evaluated against a group of findings where the highest CVSS V3 metadata entry on any of the

151
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

findings' results is 9.8.

Notice that the finding ID is accessed using {{../../id}}. You may have been expecting {{../id}}
to fetch the finding ID, since the finding is the parent of the result that was selected. However, the array of
results itself is the immediate parent, and the parent of that is the finding, so ../.. is used.

Enumerable Fields

Custom fields that are represented as one of a set of enumerable values (e.g., a set of radio buttons or a
dropdown menu) can be configured to be pre-populated by selecting the enumerable Software Risk
Manager field from the available dropdown menu. The currently defined enumerable fields are as follows:

• Severity
• Triage Status
• Detection Method
• Static Value

Once you select a Software Risk Manager enumerable field, you'll see a table with a row for each possible
value, along with a dropdown containing the possible values of your custom field. Choose which custom
values from the dropdown menu that you want to use for each Software Risk Manager value. The Static
Value option is available if you wish to define a single value for the Jira field regardless of the values in
the Software Risk Manager finding.

Issue Tracker Two-way Sync

Software Risk Manager can be configured to automatically update issue or work item fields in response to
any changes to a finding within Software Risk Manager. This is configurable on the "SRM -> *" tab.
Each field listed on the "SRM -> *" tab will have a "Keep synced" checkbox located to the right of the field's
title. Enable this option to have Software Risk Manager push updates to editable fields for issues when the
issue or work item's associated Software Risk Manager finding has changed. The values pushed to the
issue tracker will be based on the branch associated with the issue at the time of creation. Currently,
issues created via Auto Create can only be associated with a project's default branch.

Software Risk Manager can also be configured to watch specific issue or work item fields and update
associated findings accordingly. This is configurable on the "* -> SRM" tab. Currently, only single select
dropdowns and radio button fields can be mapped to affect Software Risk Manager finding Triage Status,
Severity Override and/or Fix By Date1. Note that these changes will only take effect on the issue's
associated branch; findings on other branches will be unaffected.

Note: 1. Only the Azure DevOps, GitLab, Jira and ServiceNow issue trackers support mapping of

152
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Software Risk Manager finding Fix By Date.

Automatic Status Updating

Note: This section is only applicable to Software Risk Manager users who are configuring a Jira
integration.

Software Risk Manager can be configured to automatically update Jira issue statuses in response to status
changes within Software Risk Manager. This is configurable on the "Status Mapping" tab.
Click the Projects icon in the navigation bar to open the Projects page, then select Issue Tracker Config
from the project's dropdown configuration options.
When automatic status updating is enabled, a list of Software Risk Manager triage statuses will be shown,
along with a dropdown list to pick the associated Jira status. These mappings are optional: if one is not
selected, then no action will be taken on findings with that status.
After configuring status mappings, any time the status of a finding on the issue's associated branch is
updated, the associated Jira issue will be updated according to the mapping (if applicable). If a transition is
not available, then no action will be taken. If a transition requires some input for a field, Software Risk
Manager will attempt to use any defined mappings in the "SRM -> Jira" tab that are marked "Keep synced"
to satisfy those requirements. If multiple findings are associated with the same Jira issue, the Jira status
will only be updated if all findings map to the same status.

Automatic Issue Creation

Software Risk Manager can be configured to automatically create issues or work items based on a number
of different criteria. This is configurable on the "Auto Create" tab of the Issue Tracker Configuration screen.
By default, Auto Create is disabled. To enable Auto Create, Jira and GitLab users should check the box
labeled "Automatically create issues for findings," Azure DevOps users should check the box labeled
"Automatically create work items for findings," and ServiceNow users should check the box labeled
"Automatically create incidents for findings."
After enabling Auto Create, the rest of the form will be enabled and further configuration options are
available.

Note: In contrast to manual issue creation, Auto Create currently only supports associating issues with a
project's default branch.

Issue Configuration

153
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The following configuration settings are also required:

• Issue Type. What "Issue Type" Software Risk Manager will use when creating issues or work items.
• Issue Assignee. The user Software Risk Manager will assign these issues to (Jira and ServiceNow
only; Azure DevOps and GitLab users can configure this on the "SRM -> *" tab).
• Finding Grouping. How Software Risk Manager should group findings (or not) when creating issues or
work items.
• Ticket Summary Template. The summary or title Software Risk Manager will provide when creating
issues or work items.

Finding Grouping
The "Finding Grouping" section allows users to either have Software Risk Manager create one issue or
work item per finding, or group multiple findings together per single issue or work item. If Multiple findings
per ticket, grouped by... is selected, the dropdown menu will be populated.

The selection(s) made here determines how findings are grouped. Multiple selections are allowed, but the
order of the selections matters. For example, if "Location" is selected first, and "Severity" is selected
second, Software Risk Manager will first group findings by their Location and then by their Severity.
Therefore, if you had two findings at the same location but with different severities, these findings would be

154
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

associated to different issues or work items.

Ticket Summary
The Ticket Summary - Template field determines what Software Risk Manager uses for the summary or
title when issues or work items are created. This field supports the same templates used on the field
mappings tab (i.e., "SRM -> *" tab). For example, if you want Software Risk Manager to create issues or
work items and have the summary display the finding's location and severity, you could configure a Ticket
(Work Item) Summary as follows:

{{finding.location.path.path}} {{finding.severity.name}}

The Insert placeholder... control under the input will help in determining what kind of template expression
to use.

Use Policy Rules or Filtering

The option to "Use Policy" or "Use Filters" to create issues allows users to choose to either use configured
Policy rules or the following filter options to determine which findings should have an issue automatically
created.

Note: By default, "Use Policy to create issues" is selected. Users must assign a policy to this project, and
that policy must have a rule where the action is "Create Ticket(s)." See Configuring Polices for more
information.

Filtering
SRM provides a number of options you can use to filter which findings should have issues automatically
created.

155
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

These filters include the following:

• Only create tickets or work items for New findings. If this is checked, only findings with a status of
"New" will have issues or work items created for them.
• Rule. Select any number of Rules and only findings that match the selected Rules will have issues or
work items created for them.
• Tool. Select any number of Tools and only findings that match the selected Tools will have issues or
work items created for them.
• Severity. Check any number of Severities and only findings that match the checked Severities will have
issues or work items created for them.
• Tool Overlaps. Select a number range and only findings that are in the selected Tool Overlap range will
have issues or work items created for them.
• Detection Method. Check any number of Detection Methods and only findings that match the checked
Detection Methods will have issues or work items created for them.
• CWE. Select any number of CWEs and only findings that match the selected CWEs will have issues or
work items created for them.
• Standard. Select any number of Standards and only findings that match the selected Standards will
have issues or work items created for them.

156
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

If a filter is left blank, that filter will not be used and all findings will be considered. For example, if you
leave the Severity filter blank (i.e., nothing is checked), all severities will be considered.

Configuring Project Metadata

Project Metadata allows users of Software Risk Manager to enter values into Project Metadata Fields for
any project they have the manage role for.
Click the Projects icon from the navigation bar to open the Projects page, then click the project's dropdown
configuration icon and select Project Metadata.

It is up to an admin user to define the fields; once defined, they will be available to every project in your
Software Risk Manager installation.

Adding Metadata to a Project

To add metadata to a project:

1. Click the Projects icon from the navigation bar to open the Projects page.
2. Click the project's dropdown configuration icon and select Project Metadata.
• Click Reset (a circular arrow icon) to undo any changes and return to the last saved state.
• Click Clear (an "X" icon) to clear all the fields.
3. Configure the fields as necessary.
There are four of field types:
• Text. A regular text input which allows a single line of text (e.g., Project Owner in the screenshot
above).
• Multiline. A larger text input which allows for multiple lines of text (e.g., Description in the
screenshot above).
• Dropdown. A dropdown select which allows users to pick one of the options (e.g., Criticality in the
screenshot above).
• Tags. A special input that behaves similarly to Text, but each individual word is converted to a "tag."

157
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

As you type, pressing the space bar will convert whatever text you already had into a tag.
Remember to enter a space after the last tag.
4. Click OK.

Tool Service Configuration

When the Tool Orchestration Service is enabled, the Tool Service Configuration page allows you to
configure tool orchestration for an entire Software Risk Manager project.
Click the Projects icon in the navigation bar, then click the project's dropdown configuration icon and select
Tool Config.

The Tool Service Configuration page has three sections:

• Manage Certificates
• Project Secrets
• Customize Add-In Tools

Manage Certificates
This section allows you to manage a list of certificates that tool orchestration components should trust.

158
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Manage Certificates section lets a tool or the Tool Orchestration Service handle applications that use a
self-signed certificate or a certificate issued by a certificate authority that is not well-known. Click Add
Certificate and specify a certificate file to update the list. You will see your certificate in the list after an
upload completes. Software Risk Manager will give you the option to overwrite an existing certificate file or
cancel your upload if you choose a file that is already in the list. The upload time will appear in the list
under each certificate filename to help you manage your certificates.
Deleting a certificate removes it from the list and prevents future access by tool orchestration components.
However, removing a certificate will not remove the certificate from any in-progress orchestration-related
activity.

Project Secrets
This section allows you to manage data that you can share with one or more tool orchestration
components that may require account credentials, keys, or other types of sensitive data.
Click Add New Secret to start generating data for your secret. Specify a name, and click OK to define your
list of fields.
To add a field, click Add Field. To add a sensitive field, click Add Sensitive Field. Specify a name for the
field, and click OK.
With sensitive data entry, your value is masked as you type, and you must confirm the correct value by
entering it twice. Also, sensitive values are write-only and cannot be retrieved from the API of the Tool
Orchestration Service. When you have finished specifying fields and field values, click Save to store your
secret.
Project secrets get stored as Kubernetes Secrets, so it's recommended that you follow the Kubernetes
guidance on encrypting secret data at rest (https://kubernetes.io/docs/tasks/administer-cluster/encrypt-
data/).
You can edit field values at any time. Project secrets support limited editing: you cannot change a secret's
name, add or remove fields, or change the data entry mode for a field value.
Project secrets are meant to be used with add-in tools, so Software Risk Manager will display a warning
icon to highlight those that are not yet assigned to a tool. You can learn about assigning secrets to tools in
the Customize Add-In Tools section below.

Customize Add-In Tools

This section lets you customize tools that you previously registered on the Add-In Tool page. Software Risk
Manager shows your list of registered tools on the left, and you can select a tool to enable/disable it,
assign one or more project secrets, or adjust tool behavior by changing any custom TOML configuration
data the tool can read.

159
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

What you can customize will vary by tool. For example, the default Security Code Scan tool has no project-
specific TOML configuration, and it does not read project secrets, but the Enabled/Disabled toggle lets you
customize whether it is available for your project.
Alternatively, the ZAP tool allows you to use project secrets to make authenticated requests during
scanning. The interpretation of project secret data is tool dependent—ZAP, for example, will ignore any
secrets with missing username or password fields.
The Config box shows any project-specific TOML configuration for the tool you selected.
You should avoid using the Default enabled feature for tools with project-specific TOML configuration
unless you have a process for specifying project configuration before a tool runs. Tools with insufficient
configuration details typically fail when run.
Remember to click Save to keep changes, and you must save any changes you want to keep before
selecting another tool.

Customize Checkmarx Add-In Tool

The Software Risk Manager Checkmarx Add-In has the following project-specific configuration:

[checkmarx]
baseUrl = ""
projectId = 0

[scan]
checkScanStatusDelay = 60

Use the Customize Add-In Tools feature to specify values for the above configuration before enabling the
tool. Refer to the following table for an explanation of the configuration parameters.

160
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
Parameter Description Example
The base URL endpoint for
baseUrl the Checkmarx scanner "https://cxprivatecloud.checkmarx.net"
(default="")
The Checkmarx-assigned ID
of a project created by the
projectId any integer value greater than 0
Checkmarx software at the
base URL (default=0)
The delay in seconds
checkScanStatusDe
between requests to fetch 60
lay
scan status (default=60)

Note that you may have constant values for both checkScanStatusDelay and baseUrl, so you can
specify values that will not vary by project.
You must also provide an account credential that authorizes use of the Checkmarx software at the base
URL. The Checkmarx Add-In Tool expects to find a project secret named checkmarx-project-credential that
includes both a username and a password field. The credential must grant permission to start a new scan
in the configured Checkmarx project and to generate a Checkmarx report with scan findings.

Customize ZAP Add-In Tool

The ZAP Add-In has the following project-specific configuration.

[context]
target = ""

[scanOptions]
runActiveScan = false

[reportOptions]
minRiskThreshold = 0
minConfThreshold = 0

[authentication]
type = "none"
loginIndicatorRegex = ""

[formAuthentication]

161
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

formURL = ""
formUsernameFieldName = ""
formPasswordFieldName = ""
formAntiCrossSiteRequestForgeryFieldName = ""
formExtraPostData = ""

[scriptAuthentication]
authenticationScriptContent = ""

Use the Customize Add-In Tools feature to specify values for the above configuration before enabling the
tool. Refer to the following table for an explanation of the configuration parameters.
Table 2.
Parameter Description Example
The URL where the scan
target the ZEST script for script authentication (default="")
starts (default="")
The decision to run an active
runActiveScan true
scan (default=false)
The minimum risk code for
minRiskThreshold ZAP report findings 1
(default=0)
The minimum confidence for
minConfThreshold ZAP report findings 1
(default=0)
The authentication type:
none, formAuthentication, or
type formAuthentication
scriptAuthentication
(default=none)
The regex to indicate a
loginIndicatorRege
successful login request '\QSet-Cookie: .AspNetCore.Identity.Application=\E'
x
(default="")
The URL of the login form for
formURL forms authentication "http://host.docker.internal/contosou/account/login"
(default="")
formUsernameFiel The login form's username
"Email"
dName field name (default="")
formPasswordField The login form's password
"Password"
Name field name (default="")
formAntiCrossSite The anti-XSRF token field "__RequestVerificationToken"

162
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Parameter Description Example

RequestForgeryFie
name (default="")
ldName
The extra data to include with
formExtraPostData "RememberMe=false"
login request (default="")
authenticationScrip The ZEST script for script
See ZAP documentation
tContent authentication (default="")

When you have ZAP authentication configured, you can provide account credentials by creating project
secrets that include both a username and a password field. The ZAP scanner will send authenticated
requests using each credential it finds. Be sure to specify the correct username and password with each
credential so that ZAP can log on successfully.

Orchestrated Analysis

When the Tool Orchestration Service is enabled, the Orchestrated Analyses page can be used to view the
portion of an analysis that's orchestrated on your Kubernetes cluster. Keep in mind that a Software Risk
Manager analysis may include bundled tools for which Kubernetes support is unavailable—the
Orchestrated Analysis page will not include information about those tools.

163
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Every orchestrated analysis for a project will appear in a list on the left.
Software Risk Manager will automatically select the most recent analysis when you visit the page.
Selecting an analysis lets you see summary information to include analysis status and start time. An
orchestrated analysis has a unique, numerical identifier and executes as a multi-step workflow running on
Kubernetes. Under the status information, you will find collapsed sections that represent each workflow
step. Steps labeled with an ID and tool name represent tools running on your cluster. They differ from
system steps, like prepare, which support the overall workflow.
An orchestrated analysis that completes successfully will show a Success status, also represented with a
green checkmark icon in the analysis list. Failed analyses will show a Failed status and a red exclamation
icon. The summary information for failed analyses will include a Status reason field that may provide
further information. Failed steps may also include a Message field describing why a step failed to complete
successfully.
Orchestrated analyses abandoned by previous Software Risk Manager instances continue to run to
completion. Software Risk Manager will display a message when there's an orchestrated analysis whose
results will be entered into Software Risk Manager as a brand new analysis.

Viewing Logs
Every workflow step includes one or more logs. You can expand a step section to reveal a log viewer with
support for live updates showing log data available from the Kubernetes API. Software Risk Manager
shows you the *main* log by default, but you can view log data from other available sources using the
dropdown shown below.

164
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For tool completed steps, you can click Download Logs to fetch every tool log referenced by the tool's
registration data. The Download Logs option will be unavailable when a tool run is in progress. Keep in
mind that add-in tool authors may write log data that's unavailable via the Kubernetes API, so downloaded
logs may include data that's not included in what's shown with live updates on the Orchestrated Analysis
page.
Some steps of an orchestrated analyses may repeat in an attempt to recover from unexpected failures.
How often they repeat and with what delay in between is step dependent. When log data is available for
multiple tries, a "tabbed" log viewer will be displaed. Each tab will show you the log details for a specific
attempt.

165
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Termination
Software Risk Manager lets you stop orchestrated analyses from running to completion. Click Terminate to
submit a request to cancel an analysis.

It may take a few moments before an analysis displays a terminated status, but you will see immediate
feedback indicating that your termination request has been submitted, and you will not be able to submit
additional termination requests.

Intelligent Orchestration Overview

Intelligent Orchestration can determine which security tools are best suited for a particular analysis,
depending on factors such as code changes, risk score, and security policies. In Software Risk Manager,
Intelligent Orchestration is enabled by adding a pre-scan policy to a project.

Note: Intelligent Orchestration requires a separate IO license and must be properly configured before
use. For instructions, see "Enabling Intelligent Orchestration" in the Software Risk Manager Install Guide.

166
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

To configure Intelligent Orchestration for a project:

1. Click the Projects icon in the navigation bar to open the Projects page, then select Intelligent
Orchestration from the project's dropdown configuration options.

2. Click the toggle switch to "on" to open the configuration window.

3. Enter the name of the project in the Project Name field (required).
The IO Project Name refers to an existing project in your IO server.
4. Select the SCM Type.
There are three options: GitHub, GitLab, and Bitbucket.
5. Enter the required configuration information according to the selected SCM type, as described below:
Type: GitHub
• SCM Owner
• SCM Repository Name
• GitHub API URL
• GitHub Username
• GitHub Token
Type: GitLab
• SCM Owner
• SCM Repository Name
• GitLab API URL
• GitLab Token
Type: Bitbucket
• SCM Owner
• SCM Repository Name

167
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Bitbucket API URL

• Bitbucket Host Type:
Bitbucket supports three host types:
• Cloud
• Server
• DataCenter
• BitBucket Username (Cloud only)
• BitBucket Password (Cloud only)
• Bitbucket API Version (Server/DataCenter)
• Bitbucket Project Key (Server/DataCenter)
• Bitbucket Username (Server/DataCenter)
• Bitbucket Password (Server/DataCenter)
6. Click Save.

Policies Overview

Policies in Software Risk Manager allow you to track compliance to specified requirements. Once defined,
policies can be applied to projects, and policy violations can be monitored. In this way, polices can be used
to prioritize which security issues need to be addressed, and so on.
Click the Policies icon in the navigation bar to open the Policies page.

The Policies page displays a list of all the currently defined policies, along with the following information:

• Policy Name. Lists the existing policies. Click the policy name to open the View Policy window, where
you can view or edit the policy definition.
• Status. Provides a visual representation of the policy status. There are four status icons:
• Red triangle: Fail (Overdue)
• Orange hourglass: Warn (Due Soon)
• Purple hourglass: Pass (On Track)
• Green checkmark: Pass (No Violations)
• Findings Violating Policy. Provides the following statistics:
• The total number of findings that violate the policy. Clicking the link opens the Findings page and
lists all the findings violating the policy.
• A color-coded breakdown of findings according to violation status. The numbers inside the colored
boxes correspond to the number of findings for each category: Overdue (red), Due Soon (orange),
On Track (purple), No Fix-by date (gray). Clicking a box opens the Findings page. Findings are
sorted according to the corresponding Policy Violations and Policy Violation Urgency filters.

168
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• The number of assigned projects with policy violations. Clicking the link opens the Projects modal,
which lists the projects using this policy.
• Using This Policy. Shows the number of projects using the selected policy. Clicking the link opens the
View Policy Projects window, which lists all the projects associated with the policy.

Click the column headers to re-sort the list. You can also use the search field to search for a specific policy.

Working with Policies

For more information on policy management, see the following topics:

• Policy Configuration. How to view a policy's configuration.

• Creating and Editing Policies. How to create or edit a policy's configuration.
• Applying a Policy to a Project. How to apply a single policy to a project.
• Applying a Policy to Multiple Projects. How to apply a policy to multiple projects.
• Monitoring Policy Violations. How to track policy violations as they relate to projects, policy, and
individual findings.

Policy Configuration

A policy consists of three parts:

• Description. The policy name and its purpose.

• Rules. The conditions that define the policy.
• Projects. The projects that will use the policy.

When creating, editing, or viewing policies, each part—Description, Rules, Projects—will be displayed in a
separate window. Clicking the "button" tabs along the top will switch to that corresponding window. Click
Done to close the window.

169
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Viewing Policy Configuration

Policy definitions can be displayed from the Policies page.
To view the configuration of an existing policy:

1. Click the Policies icon in the navigation bar to open the Policies page.

2. Click a policy name to open the Policy Description window for that policy.

The Description window displays the following information:

• Policy Name. The name of the policy.
• Description. A description of the policy.
• Filter Rules. The number of rules used to define the policy. Click the link to display the filter rules.
(This is the same as clicking the Rules tab.)
• Projects Using this Policy. The number of projects that use this policy. Click the link to display a
list of projects that use this policy. (This is the same clicking the Projects tab.)

Note: Click Done to close the window. Click Close and Edit to open a window where you can edit the
policy's configuration. For more information, see Creating a Policy.

3. Click the Rules tab to see a list of all the rules that define the policy.

170
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

4. Click the Projects tab to see a list of all the projects that use this policy.

Use the search field to search for specific projects.

5. Click Done to close the window.

Additional Policy Configuration Options

Click the policy's dropdown configuration icon to display additional options:

171
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• View. Opens the policy Description window (same as clicking a policy name).
• Edit. Opens the policy configuration page where you can edit the policy's configuration (see Creating a
Policy).
• Duplicate. Creates a new policy with duplicate settings. This is useful when creating a new policy that
includes many of the same rules as the original. Creating a policy with duplicate settings eliminates the
need to recreate rules that have already been defined.
• Set as default. Specifies that the policy will be automatically assigned to all new projects (but not to
existing ones). If a policy is a default policy, it will appear as part of the policy name. (A default policy
must be "unset as the default" before it can be deleted.)
• Delete. Deletes the policy and all its associations with existing projects. Deleting a policy is irreversible.
A warning pop-up window will list all the projects associated with the policy and ask for confirmation
before deleting the policy.

Creating and Editing Policies

Policies are created and updated from the Policies page. (Note that there are often alternative ways to
perform the same task. The most common are detailed below.)

• Creating a Policy
• Editing a Policy
• Deleting a Policy

Note: Policy functionality is role-based: users assigned to the "Manager" role are limited to assigning and
removing projects.

Creating a Policy
To create a new policy:

1. Click the Policies icon in the navigation bar to open the Policies page.

172
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click Add Policy to open the policy description window.

3. Enter a name (required) and description for the policy

The policy name must be unique. A description is not required, but it is recommended.
4. Configure the sharing settings for the policy, then click Next.
By default, a policy can only be viewed and edited by the user who creates it. Once projects are
associated to the policy, any users who can view at least one of those projects will be able to view the
policy.

173
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

5. Click Add Rule to assign rules to the new policy.

Clicking Add Rule opens a dialog where you can configure new rules.

6. Use the dropdown options to configure the policy rule.

Creating a rule includes configuring the following elements:
• On/Off toggle. Allows individual rules to be temporarily deactivated.
• Threshold. Sets the minimum number of findings needed to trigger the rule.
• Filter. Defines which filters the policy will use. Select filters from the dropdown list. (Note: Private
saved filters must be shared before they can be applied. For more information, see Saving Filters.)
Use the search field to search for existing filters.

174
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: Regarding the use of the Policy Violations and Policy Violation Urgency filters in saved
private filters, if either (or both) of these filters are added to a saved filter, those options will be
ignored when using that filter as a Policy rule.

• Fix by. Sets the number of days before the violation status changes to overdue. Select the number
of days from the dropdown list. Select "Not Required" if no date is necessary.

• Action. Specifies what action should be taken when the rule is violated. The options are "Nothing,"
"Create ticket(s)," and "Break Build."

7. Click Next to open the Projects window.

175
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

8. Click Add Project to open the Add Projects to Policy window.

9. Select the projects to associate with this policy and click Add Projects.
Use the checkboxes to select projects. You can search for projects using the search field. The Current
Policies column shows the number of policies that have already been assigned to that project.
10. Click Finish.

Editing a Policy
To edit an existing policy:

1. Click the Policies icon in the navigation bar to open the Policies page.

176
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Click the policy's dropdown configuration icon and select Edit.

3. Make changes as necessary.

For field definitions, see the descriptions in the Creating Policies section.
4. Click Finish.

Deleting a Policy
To delete an existing policy:

1. Click the Policies icon in the navigation bar to open the Policies page.

2. Click the policy's dropdown configuration icon and select Delete.

177
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Click Delete to confirm.

Applying a Policy to a Project

There is more than one way to apply a policy to a project. The instructions below detail the most common
method of applying a single policy to a single project.
To apply a policy to a project:

1. Click the Projects icon in the navigation bar to open the Projects page.

2. Click project's dropdown configuration icon and select Policy Associations.

178
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This will open the Policy Associations window.

3. Click Assign Policy and select which policy(ies) to add from the list.
Click the plus icon to select policies. You can search for policies using the search field. Clicking the
minus icon next to an existing assignment will remove the policy association from the project. (For
information on creating a policy, see Creating and Editing Policies.)
4. Click Save Changes.

Applying a Policy to Multiple Projects

There is more than one way to apply a policy to multiple projects. The instructions below detail the most
common method.
To apply a policy to multiple projects:

1. Click the Policies icon in the navigation bar to open the Policies page.

2. Click the policy's dropdown configuration icon and select Edit.

179
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Click the Projects tab.

4. Click Add Projects and select the projects you want to apply this policy to.

Use the checkboxes to select projects. You can search for projects using the search field. The Current

180
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Policies column shows the number of policies that have already been assigned to that project. Clicking
the minus icon removes the project association.
5. Click Add Projects.
6. Click Finish.

Monitoring Policy Violations

Once a policy has been defined and applied to a project, Software Risk Manager will track policy violations
and provide violation status in a variety of ways. Policy information and violation status appears on the
following pages:

• Projects page
• Findings page
• Policies page

Note: Email notifications for changes to policy violation status can be configured on the user
configuration page. For more information, see User Configuration Settings. For information on
customizing the policy email template, see Customizing the Policy Email Template.

Understanding Policy Violation Parameters

You can set the "duration" or number of days before a policy is violated when you create policy rules. Time-
based violations are based on calendar days. Polices can be set to preselected periods, that is, 1 day, 7
days, 14 days, etc. The "fix-by" date is calculated based on the day the finding was created. For example,
if a rule has been set to 7 days, the policy will show a violation 7 days after the finding was created.
Tickets will be created whenever a finding violates the findings matching condition; nevertheless, the
threshold or fix-by date doesn't need to be reached. Consider the following example:

If > 100 findings matching Only Critical and Highs, fix by 14 days and Creat
e
Tickets

If your project only has one new critical or high finding, a ticket will be created for that finding even though
the policy itself is still passing because it hasn't hit the threshold and hasn't gone over the fix-by date
When using the Policy filters, note the following range definitions:

• Due Soon is 0–7 days.

• On Track is anything over 7 days.
• Overdue occurs when the fix-by date has passed by at least one day.

181
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Monitoring Policy Violations for Projects

Click the Projects icon in the navigation bar to view a summary of policy issues related to a specific project.

This page shows the number of policy violations for each project along with links to additional information.
Policy information is displayed in the second and third columns to the right of the total number of findings
for that project. The total number of policy violations for a specific project is broken out by policy violation
status, shown in color-coded boxes. Clicking a box takes you to the Findings page, where the findings
have been filtered according to that status.

Policy violations are defined as follows:

• Red: Overdue
• Orange: Due soon
• Purple: On track
• Gray: Unspecified "fix-by"

The third column shows the number of policies associated with that project. Clicking the link displays the
policies associated with that project.

Monitoring Policy Violations for Findings

Policy violations for a single finding can be found on the Findings page. Click the Findings icon from the
navigation bar to open the Findings page, then mouse over the shield icon next to the finding ID to see a
summary of policy violations for that finding. The number of days specified to fix the issue is displayed in
the "Fix By" column.
You can also use filters to sort findings based on policy violations. For more information, see Working with
Filters.

182
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Integrations Overview

Click the Integrations icon in the navigation bar to open the Integrations page.

The default view lists all the currently configured integration tools.

• Use the menu on the left to display supported tools arranged by tool type.
• Select All to display all the analysis tools, integration tools, IDEs, issue tracking systems, plugins, and
version control tools supported by SRM.
• Select Configured to display all the currently configured integration tools.
• Enter a search term in the Search Integrations field to search for a specific tool.

Integration Tool Types

SRM supports the following types. (Click the link for additional information.)

183
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Analysis Tools
• Continuous Integration
• Integrated Development Environments
• Issue Tracking
• Plugins
• Source Code Management

Analysis Tools
SRM supports the following Analysis Tools:

• 42Crunch
• Acunetix Desktop (XML)
• Acunetix 360
• Anchore (JSON)
• Android Lint (XML)
• APIsec
• AppScan DAST (XML)
• AppScan Enterprise
• AppScan Source (OZASMT)
• AppSpider (XML)
• Aqua Enterprise
• Arachni (JSON and XML)
• Armorize CodeSecure (XML)
• ASoC (XML)
• AWS Security Hub (JSON)
• Azure Security Center (CSV)
• Black Duck SCA
• Black Duck Binary Analysis (CSV and JSON)
• Brakeman (JSON and ZIP of JSON outputs) (Built-in tool)
• Burp Enterprise
• Burp Suite (XML)
• C++test (XML)
• CAT.NET (XML) (Built-in tool)
• Checkmarx (XML)
• Checkmarx IAST
• Checkmarx One
• Checkstyle (XML) (Built-in tool)
• Clang (ZIP of HTML outputs)
• Clang-Tidy (TXT: console log)
• Clippy (JSON and ZIP of JSON outputs) (Built-in tool)
• CodePeer (CSV)
• CodeSonar (CodeSonar-Scrape ZIP)
• Contrast
• Coverity (JSON v8+)
• Coverity on Polaris
• Cppcheck (XML v2) (Built-in tool)
• CycloneDX (JSON and XML)
• Data Theorem Mobile

184
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• DefenseCode ThunderScan (JSON)

• Defensics Fuzz Test (XML: super-summary.xml)
• Dependency-Check (XML) (Built-in tool)
• Dependency-Track
• dotTEST (XML)
• Dynatrace
• ErrCheck (TXT: console.log)
• error-prone (TXT)
• ESLint (JSON) (Built-in tool)
• Faraday
• Fortify (FPR)
• Fortify Software Security Center
• FxCop (XML and ZIP of XML outputs) (Built-in tool)
• Gendarme (XML) (Built-in tool)
• GitHub Advanced Security
• GitLab Security (JSON) and Report (ZIP)
• GoCyclo (TXT: console log)
• GoLint (TXT: console log)
• GoSec (JSON)
• Grype (JSON)
• Hacker One
• Harbor (JSON and CSV)
• Helix PRQA-QAC (CSV)
• Imperva
• IneffAssign (TXT: console log)
• Inviciti (XML)
• Inviciti Enterprise (XML: Vulnerabilities List)
• IriusRisk
• JFrog Xray (JSON)
• Jlint (TXT)
• JSHint (TXT) (Built-in tool)
• Jtest (TXT) (Built-in tool)
• Mend SCA
• Microsoft Defender For Cloud
• Microsoft Code Analysis (TXT: MSBuild log and TSV: errors table)
• Microsoft Threat Model (HTM and TM7)
• MobSF (JSON: Generate JSON Report endpoint)
• MobSF Scan (JSON)
• NDepend (XML)
• Nessus (NESSUS)
• NeuVector
• Nmap (XML)
• NowSecure
• NowSecure Workstation (JSON and ZIP of JSON outputs)
• OCLint (XML)
• Orca Security
• PHP_CodeSniffer (XML) (Built-in tool)
• PHPMD (XML) (Built-in tool)
• PMD (XML) (Built-in tool)

185
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Polaris
• Prisma Cloud (RedLock) (CSV and JSON: List Alerts V1 endpoint)
• Prisma Cloud Compute (Twistlock) (CSV and JSON)
• Pylint (JSON and ZIP of JSON outputs)
• Q-MAST
• Qualys CS (CSV)
• Qualys VM (XML)
• Qualys VMDR
• Qualys WAS
• Rapid Scan SAST (JSON)
• Rapid7 InsightAppSec
• Rapid7 Nexpose (XML)
• SafeSQL (TXT: console log)
• SARIF (JSON v2.1.0)
• SATE (XML)
• Scalastyle (XML) (Built-in tool)
• SCAP (XML)
• SciTools Understand (CSV)
• SD Elements
• Black Duck Seeker
• Semgrep (JSON)
• Snyk (JSON)
• SonarQube
• Sonatype Nexus
• SPDX (JSON and SPDX)
• SpotBugs (XML) (Built-in tool)
• SRM Custom Integration (XML)
• Staticcheck (JSON)
• STIG (CKL)
• SWAMP (XML)
• Black Duck Managed Services Platform (XML)
• Tenable.io
• Tenable.io Web App Scanning
• Tenable.sc
• Black Duck Tinfoil API
• Black Duck Tinfoil Web
• Trivy (JSON: container image results)
• TruffleHog (JSON)
• Trustwave App Scanner
• Veracode (XML and ZIP)
• Vet (JSON)
• WebInspect (XML)
• WhiteHat
• Wiz
• WPScan (JSON)
• ZAP (XML)
• ZPA (JSON) (Built-in tool)

186
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Continuous Integration
SRM supports the following CI tools (click the link for more information):

• Azure DevOps Pipelines

• Bamboo
• GitHub Action
• Jenkins
• Black Duck SRM API
• Black Duck Bridge CLI
• TeamCity

Integrated Development Environments

SRM supports the following IDEs (click the link for more information):

• Code Sight IntelliJ

• Code Sight Visual Studio Code
• Eclipse
• Visual Studio

Issue Tracking
SRM supports the following issue tracking tools (click the link for more information):

• Azure DevOps
• GitHub
• GitLab
• Jira
• ServiceNow

Plugins
SRM supports the following plugins (click the link for more information):

• Burp
• Splunk
• ZAP

Source Code Management

SRM supports the following SCM systems (click the link for more information):

• Git

Analysis Tools

187
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Click the Integrations icon in the navigation bar and select Analysis Tools to open the Analysis Tools page.

Use the Search field to search for a specific tool.

Configuring an Analysis Tool

To configure an analysis tool:

1. Click the Integrations icon in the navigation bar and select Analysis Tools to open the Analysis Tools
page.
2. Click the Set Up button for the tool you want to configure.
Not all tools are configurable.

3. Click Add Connection.

188
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

a. Add an API token with "API Security Audit" rights in the API Token field.
To test the connection, click the Test Connection button.
b. Select sharing options with users or user groups.
c. Select permissions.
4. Click Add Options.

5. Enter a name in the Options Name field and select which options to include.
6. Click Save Options.
Note that you can edit existing options.
7. Select Schedules from the upper menu.
8. Click Add Schedule.

189
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

9. Add projects.

Migrating Existing Tools to SRM

SRM’s centralized configuration functionality allows Software Risk Manager to act as a hub for interacting
with tool connectors. For Code Dx users migrating to Software Risk Manager, existing tool connectors can
be converted to take full advantage of SRM’s centralized configuration. (In an upcoming release of SRM,
legacy tool connectors will be converted automatically, consolidating common information, such as
connection URLs and credentials, into more-easily-managed shared entities.)
To migrate legacy tool connectors (Code Dx) to take advantage of centralized configuration, SRM provides

190
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

two URLs that an administrator can use to perform the conversion:

• The first URL performs a "dry run" of the conversion, providing a report of all the decisions and
consolidations that will be made during the actual conversion process.
• The second URL performs the conversion.

To perform the dry run and see a text-based report, log in as an admin and enter the following into your
browser: <SRM Base URL>/x/integrations/tool-connector/migration/dry-run. You can
also use your HTTP client-of-choice to send a GET request to that URL to obtain the report.
To trigger the actual conversion, use <SRM Base URL>/x/integrations/tool-connector/
migration/commit-run. This URL responds with a 204 No Content upon success.

Warning: Running the conversion is irreversible. Making a backup of your database prior to performing
this action is highly recommended.

Continuous Integration

Click the Integrations icon in the navigation bar and select CI to open the Continuous Integration page.

Use the Search field to search for a specific tool.

SRM supports the following CI tools (click the link for more information):

• Azure DevOps Pipelines

• Bamboo
• GitHub Action
• Jenkins
• Black Duck SRM API
• Black Duck Bridge CLI

191
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• TeamCity

Integrated Development Environments

Click the Integrations icon in the navigation bar and select IDEs to open the IDEs page.

Use the Search field to search for a specific tool.

SRM supports the following IDEs (click the link for more information):

• Code Sight IntelliJ

• Code Sight Visual Studio Code
• Eclipse
• Visual Studio

Issue Tracking

Click the Integrations icon in the navigation bar and select Issue Tracking to open the Issue Tracking page.

Use the Search field to search for a specific tool.

SRM supports the following issue tracking tools (click the link for more information):

192
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Azure DevOps
• GitHub
• GitLab
• Jira
• ServiceNow

Plugins

Click the Integrations icon in the navigation bar and select Plugins to open the Plugins page.

Use the Search field to search for a specific tool.

SRM supports the following plugins (click the link for more information):

• Burp
• Splunk
• ZAP

Source Code Management

Click the Integrations icon in the navigation bar and select SCM to open the Source Code Management
options.

193
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Use the Search field to search for a specific tool.

SRM supports the following SCM systems (click the link for more information):

• Git
• GitHub

Bulk Onboarding with GitHub Repositories

Software Risk Manager can automatically create projects based on existing GitHub repositories.
Click the Integrations icon in the navigation bar and select SCM to open the Source Code Management
page.

Configuring the Connection to a GitHub Repository

To configure the connection to a GitHub repository:

194
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. Click the Integrations icon in the navigation bar and select SCM to display the GitHub option.

2. Click the configuration icon for GitHub, then select the Connections tab from the top menu.

3. Click Add Connection.

4. Enter a Connection Name and Access Token.

Use the Test Connection button to verify proper configuration.
5. Click Save.
With a saved connection, you can create projects from your GitHub repositories as well as associate

195
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

GitHub repositories with existing projects.

Synching GitHub Repositories with SRM

To sync GitHub repositories with SRM:

1. Click the Integrations icon in the navigation bar and select SCM to display the GitHub option.

2. Click the configuration icon for GitHub, then select the Repositories tab from the top menu.

196
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Select a connection from the dropdown menu.

4. Use the checkboxes to select which repositories to sync with Software Risk Manager.
5. Click Create Projects.

6. Specify the following parameters:

• Naming Convention. The template is a https://handlebarsjs.com/ expression. The available fields
are as follows:
• organization. The organization name.

197
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• repository. The repository name.

• isPrivate. Specifies whether the repository is private.
• isArchived. Specifies whether the repository is archived.
• isFork. Specifies whether the repository is a fork.
• languages. A list of languages in the repository.

Note: When the name (chosen by the naming convention) for a repository corresponds to an
existing SRM Project, SRM will associate the repository with the existing project rather than
creating a new project, but only if the user has the manage role for that project.

• Parent Projects. Enables you to specify a parent project for the projects you are creating.
• Analyses. Instructs SRM to run an analysis after creating the new projects.
7. Click Create Projects.
The new projects will appear on the Projects page.

Clicking the git branch icon opens the SCM Configuration window, which displays the connection name
and repository URL.

To delete the repository, click the Delete Configuration button.

For projects that are set up with a git configuration, SRM will automatically create a ZIP archive of the files
from that git repo and include it in the analysis prep area as a "source from" item, as shown in the example
below.

198
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Analyses Overview

When the Scan Farm has been configured, Software Risk Manager can automatically run Coverity SAST
and Black Duck SCA scans. Software Risk Manager also comes with bundled open source tools to scan a
wide variety of applications. Supported languages and expected inputs for the built-in open source
scanners are described in the Built-in Open Source Code Scanners and the Built-in Open Source
Dependency Scanners sections. In addition to the bundled tools, Software Risk Manager can import the
results of several commercial and open source tools. The supported tools and generic input formats are
described in the Importing Scan Results section. There are a number of different options to configure and
run analyses for Software Risk Manager: manually using the web interface, Jenkins plugins, or
automatically (such as from your continuous integration server) using the API or using Black Duck Bridge
CLI. These are all detailed in the Starting Analyses section.

Incremental Analysis
Software Risk Manager performs analyses incrementally. This means that as new analysis inputs (files)
are added to a project, any findings associated with them are added to the project.
The life of a finding is tied to the inputs in which it was reported. When the last input contributing to a
finding is archived, the finding itself is marked as "Gone" and hidden by default (see Findings View
Options).
Analysis inputs can be archived manually or automatically. For more information on archival, see Auto-
Archival.

Built-In Open Source Code Scanners

Software Risk Manager bundled open source code analyzers can analyze C/C++, Objective-C, Java,
JavaScript, JSP, .NET (C#, VB), PHP, Terraform, Docker, Swift, Scala, Python, Ruby on Rails, and Rust
applications. For all supported languages, Software Risk Manager will analyze the source using open
source bundled tools built specifically for a target language. For applications built with any combination of
the supported languages, Software Risk Manager will run the appropriate checkers on the provided
source.

199
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: The Software Risk Manager built-in open-source code scanners are turned off by default and can
be turned on from the Integrations page. For more information, see the Integrations Overview section.

For Java applications, Software Risk Manager bundled open source code analyzers supports scanning
compiled bytecode. In fact, the preferred approach for Java projects is to upload both source and
bytecode to Software Risk Manager in the supported file format described in the bullets below. This yields
the best coverage for issue detection.
For .NET applications, Software Risk Manager supports scanning compiled DLLs. It is also recommended
that the source be uploaded. This will provide better source location information and will allow for viewing
the source while looking at finding details.

Note: If you choose to upload an entire Visual Studio solution folder, there may be duplicates of the build
DLLs and third-party DLLs. This will cause a longer analysis time and possibly incorrect results if some
DLLs are stale. To achieve the best results, upload a zip that contains only the DLLs and PDB files for
the binaries you wish to analyze. Upload the source as a separate zip.

Accepted zip Archive Formats

Software Risk Manager accepts application inputs in the following zip archive formats for running bundled
open source tools:

• C/C++. .zip containing C/C++ source files that will be analyzed by Software Risk Manager bundled
tools. Software Risk Manager will scan the .zip file for .h, .c, .hpp, and .cpp files. (Note: If your
project contains Objective-C source files then .h files will be treated as Objective-C rather than C/C++).
• Java source. .zip containing Java source files – with a .java extension – to be analyzed by the
Software Risk Manager bundled tools.
• Java bytecode. .zip containing .class or .jar bytecode files intended for the JVM.
• .NET. .zip containing C# or VB.NET source files – with a .cs or .vb extension.
• .NET DLLs. .zip containing compiled .dlls. You must also include the PDB files for .dlls you wish
to scan. Software Risk Manager will only scan .dlls with corresponding PDB files – unless there are
no PDB files, in which case Software Risk Manager will scan all .dlls but source location information
may be sub-optimal.
• iOS. .zip containing .ipa files. (Note: This detection is only for associating add-in tools with these
files).
• Windows UWP. .zip containing .appx files. (Note: This detection is only for associating add-in tools
with these files).
• Ruby on Rails. .zip containing Ruby source files that are inside an app/ directory.
• PHP. .zip containing PHP source files.
• PL/SQL. .zip containing PL/SQL source files.
• Python. .zip containing Python source files.
• JavaScript. .zip containing .js files; minified JavaScript will be ignored.
• Scala. .zip containing .scala files.
• Swift. .zip containing .swift files.

200
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Objective-C. .zip containing .m, .mm, .M, .h files. (Note: '.h' will only be detected as Objective-C if
there are other Objective-C file types in the '.zip').
• Terraform. .zip containing .tf files.
• Docker. .zip containing Dockerfile files. Note that this has no extension.
• Rust..zip containing Rust project files. Software Risk Manager will scan the .zip archive for the
Cargo.toml file (which is the manifest for Rust projects) and .rs source files.

Note: Software Risk Manager enforces a single source .zip archive per analysis. Although Software
Risk Manager supports multiple languages, the expectation is that they will all be packaged in a single
.ziparchive to enable consistent path correlation across all the checkers. And while source and
bytecode inputs can be uploaded in separate files, they do not have to be split up. A single .zip file
containing C/C++ source, Java source, Java bytecode, .NET DLLs, .NET source, PHP source, Scala
source, Ruby on Rails source, Python source, JavaScript source and Rust source is perfectly acceptable.

Bundled Open Source Tool Versions

The bundled tool versions are listed in the table below.

Table 1.
Tool Version Release Date
Brakeman 5.2.0 12/16/2021
Checkstyle 8.32 4/26/2020
Clippy (user-installed)
Cppcheck 2.9 8/28/2022
Dependency-Check 12.1.0 2/16/2025
ESLint 8.54.0 11/17/2023
FxCop (user-installed) 10+ Not available
Gendarme (not available in containerized
deployments such as Docker Compose or 2.11.0 Not available
Kubernetes)
JSHint 2.13.5 7/8/2022
PHP CodeSniffer 3.7.1 6/18/2022
phpcs-security-audit 2.0.1 8/5/2019
PHPMD 2.13.0 9/10/2022
PMD 6.54.0 1/28/2023
Pylint 2.4.4 11/13/2019
Scalastyle 2.12–1.0.0 8/20/2017

201
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Tool Version Release Date

SpotBugs 4.8.6 6/17/2024
SpotBugs Find Security Bugs 1.13.0 2/26/2024
ZPA CLI 1.2.0 12/19/2021

Built-In Open Source Dependency Scanners

Software Risk Manager also scans input to check for dependencies with known vulnerabilities.
The following dependencies are checked:

• Java: .jar and .war files in Java projects.

• .NET: .exe and .dll files in .NET projects.
• JavaScript files are checked by name or a hash of the file (minified JavaScript incorporated into a
different source file will not be checked).

Importing Scan Results

Software Risk Manager supports importing the results of commercial and open source application security
testing tools as well as a couple of generic tool result listing formats. The list of supported tools for scan
imports includes the built-in ones mentioned in the previous section. If one of the tools you want to import
is not supported, please let us know. However, in the meantime, you can convert your data to the generic
SRM Input XML format. The schema definition for this format and an example can be accessed via the
download icon in the Software Risk Manager header.

Note: Some tools will output empty files if no results were found, which cannot be detected by Software
Risk Manager as any particular format. For more information on empty or undetected tool results, see
Empty/Undetected Tool Results.

Supported Tools
Software Risk Manager supports various tools and tool types, including the following:

• SAST tools
• DAST tools
• IAST tools
• Mobile tools
• InfraSec tools
• Threat Modeling tools
• Component tools
• Container tools
• Cloud Infrastructure tools
• Bug Bounty tools
• Infrastructure as Code (IaC)
• Web Application Firewall (WAF)

202
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Security Technical Implementation Guide (STIG)

Additional Support for Selected Tools

Software Risk Manager also provides additional support for the following tools:

• AppDetective Pro
• AppSpider
• Aqua
• CodeSonar
• Dynatrace
• Helix QAC
• Parasoft
• Prisma Cloud Compute (Twistlock)
• SARIF
• SBOM Files

SAST Tools
Software Risk Manager supports the following SAST tools and import formats:

• 42Crunch: a Tool Connector for Security Audit scans.

• Android Lint: .xml and .zip.
• Armorize CodeSecure: .xml.
• Brakeman is a built-in scanner; .json is also supported.
• Checkmarx: .xml and a Tool Connector.
• Checkmarx One: a Tool Connector.
• Checkstyle is a built-in scanner; .xml is also supported.
• Clang: .zip containing one or more .html or .plist.html (CodeChecker) files. (Clang outputs one
HTML file per checked source file.)
• Clippy (user-installed) is a built-in scanner; .json is also supported.
• CodePeer: .csv reports.
• CodeSonar-Scrape: see the CodeSonar-Scrape utility section for details.
• CppCheck is a built-in scanner; v2 .xml is supported as well.
• Coverity: .json using the cov-format-errors command line tool. For example: cov-format-
errors --dir /tmp/idir --json-output-v10 file.json. When Scan Farm is configured,
Coverity is available as a built-in tool.
• Coverity on Polaris: a Tool Connector.
• Coverity Connect: a Tool Connector.
• DefenseCode ThunderScan: .json report and a Tool Connector.
• ErrCheck: plain-text (e.g., .txt) with console output redirected to a file.
• error-prone: plain-text such as .txt.
• ESLint is a built-in scanner; .json is also supported.
• Fortify: .fpr.
• Fortify Software Security Center: a Tool Connector.
• FxCop (user-installed) is a built-in tool; .xml is also accepted.
• Gendarme is a built-in tool (not available in containerized deployments such as Docker Compose or
Kubernetes); .xml is also supported.

203
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• GitHub Advanced Security (Code Scanning): a Tool Connector.

• GitLab Security: .json and Report .zip.
• GoCyclo: plain-text (e.g., .txt) with console output redirected to a file; it may contain build errors.
• GoLint: plain-text (e.g., .txt) with console output redirected to a file; it may include build errors
• GoSec: .json when using the -fmt json flag.
• HCL AppScan Source: .ozasmt.
• HCL AppScan on Cloud (ASoC): .xml and a Tool Connector.
• Helix QAC: .csv report containing Helix QAC Rule Compliance results; see the Helix QAC Support
section for more information.
• IneffAssign: plain-text (e.g., .txt) with console output redirected to a file.
• JLint: plain-text such as .txt.
• JSHint is a built-in tool; plain-text such as .txt is supported.
• Microsoft Code Analysis log files containing Roslyn analyzer results from MSBuild or Visual Studio as
.txt files. Additionally, a copy/pasted .tsv output from the Error List table in Visual Studio with
Entire Solution analysis enabled, which must contain the Code, Description, Line, and File
(or Path) columns, and may optionally include the Column column. Furthermore, rules from the Code
Cracker and Security Code Scan Roslyn analyzers, which are in the .tsv and .txt file formats
as previously described.
• MobSF: .json where the JSON is generated by exporting a JSON file using the API, api/v1/
report_json.
• MobSF Scan: .json.
• NDepend: .xml file containing NDepend Rule Results.
• OCLint: .xml.
• Orca Security: a Tool Connector.
• Parasoft JTest/C++Test/dotTest: .xml; please see the Parasoft Support section for more information.
• PHP_CodeSniffer is a built-in tool; .xml is also supported.
• PHPMD is a built-in tool; .xml is also supported.
• PMD is a built-in tool; .xml is also supported.
• Pylint is a built-in tool; .json is also supported.
• Polaris: a Tool Connector.
• Rapid Scan SAST: .json.
• SafeSQL: plain-text (e.g., .txt) with console output redirected to a file.
• SARIF .json format in compliance with SARIF v2.1.0 schema; please see the SARIF Support section
for more information.
• SATE: .xml format for NIST’s Static Analysis Tool Exposition V (SATE V).
• Scalastyle is a built-in tool; .xml is also supported.
• SCARF: .xml for SWAMP Common Assessment Result Format.
• SciTools Understand: .csv report containing SciTools Understand analysis results.
• Semgrep: .json and a Tool Connector.
• Snyk Code: a Tool Connector; .json is supported.
• Software Risk Manager XML: for cases where you have data from a custom tool or from a tool that
isn’t supported by Software Risk Manager, you can convert the output to the Software Risk Manager
.xml format and input that directly for analysis. XML schemas and examples are provided via the
download icon in the Software Risk Manager header.
• SonarQube/SonarCloud: a Tool Connector.
• SonarQube Generic Issue Import Format: .json.
• SpotBugs/FindBugs is a built-in scanner; .xml outputs are also accepted.

204
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Staticcheck: .json when using the -f json flag, with its console output redirected to a file.
• TFLint: .json file in compliance with SARIF format when using the -f sarif format option with
tflint command. Software Risk Manager currently allows importing TFLint results in SARIF format
only. The -f (or --format) option can be used to generate the SARIF formatted console output, which
can then be redirected to a file, for example: tflint -f sarif <file or directory>.
• TruffleHog: .json file with repository scan results.
• Veracode: either the .zip files generated when exporting XML results, or the .xml files contained
within them. Additionally, Veracode is a Tool Connector.
• Vet: .json from go vet by using the -json flag, with console output redirected to a file. It may
include build errors.
• WhiteHat: a Tool Connector.
• ZPA: .json using the zpa-cli command line tool, with the sq-generic-issue-import output-
format.
• Other source zip archives: .zip (zipped source archives display contextual source for findings on the
Finding Details page).

DAST Tools
Software Risk Manager supports the following DAST tools and import formats:

• Acunetix Desktop: .xml where the XML is generated by selecting Scans, then Select Scan, then
WAF Export, and then XML.
• Acunetix 360: a Tool Connector.
• AppSpider Vulnerability Summary: VulnerabilitiesSummary.xml; see the AppSpider Support
section for more information.
• Arachni: .json.
• APIsec: a Tool Connector.
• Burp Suite: .xmlwhen the Base64 encoding option is selected; consider using our Burp Suite plugin
to send results directly to Software Risk Manager.
• Defensics Fuzz Test: super-summary.xml.
• Dynatrace: a Tool Connector (Attack data only).
• Fortify WebInspect: .xml when these options are selected: File, then Export, then Scan Details. In
the Settings section, choose Full from the "Details:" dropdown menu and click Export.
• HCL AppScan Standard: .xml.
• HCL AppScan on Cloud (ASoC): .xml and a Tool Connector.
• Imperva: a Tool Connector.
• Invicti Standard (formerly Netsparker): .xml.
• Invicti Enterprise (formerly Netsparker Enterprise): Vulnerabilities List .xml report and a Tool
Connector.
• OWASP ZAP: .xml; consider using our OWASP ZAP add-on to send results directly to Software Risk
Manager.
• Qualys WAS: a Tool Connector.
• Polaris: a Tool Connector.
• Rapid7 InsightAppSec: a Tool Connector.
• Rapid7 InsightVM: a Tool Connector.
• Rapid7 Nexpose: .xml generated with the XML Export or XML Export 2.0 reports. See Rapid7
Nexpose Working with report formats and Report templates and sections for more information.

205
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Black Duck Managed Services Platform: .xml report and a Tool Connector.
• Tenable.io Web App Scanning: a Tool Connector.
• Tinfoil API: a Tool Connector.
• Tinfoil Web: a Tool Connector.
• Trustwave App Scanner: a Tool Connector.
• Veracode: .xml and .zip. Additionally, Veracode is a Tool Connector.
• WhiteHat: a Tool Connector.
• WPScan: .json.
• sqlmap output - Sqlmap does not provide a suitable output format; to that end we've developed a fork
of sqlmap, which has flags for exporting in the Software Risk Manager Custom XML format.

IAST Tools
Software Risk Manager supports the following IAST tools and import formats:

• Checkmarx: a Tool Connector.

• Contrast: a Tool Connector.
• HCL AppScan on Cloud (ASoC): .xml and a Tool Connector.
• NowSecure Workstation: .json.
• Q-MAST: a Tool Connector.
• Black Duck Seeker: a Tool Connector.

Mobile Tools
Software Risk Manager supports the following Mobile tools and import formats:

• Data Theorem Mobile Secure: a Tool Connector.

• HCL AppScan on Cloud (ASoC): .xml and a Tool Connector.
• MobSF: .json where the JSON is generated by exporting a JSON file using the API, api/v1/
report_json.
• MobSF Scan: .json.
• NowSecure: a Tool Connector.
• NowSecure Workstation: .json.

InfraSec Tools
Software Risk Manager configured with the InfraSec add-on supports the following Infrastructure tools and
import formats:

• AppDetective Pro: .xml Check Results reports; please see the AppDetective Pro Support section for
more information on report requirements.
• Tenable Nessus: .nessus.
• Tenable.io: a Tool Connector.
• Tenable.sc: a Tool Connector.
• Rapid7 Nexpose: .xml.

206
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• NMap: .xml that contains vulnerability information associated with scripts written using the NMap
Scripting Engine.
• Qualys VM: .xml generated with Scan-Based and Host-Based report templates and a Tool Connector.
Before generating a report with a Host-Based report template, ensure that "Vulnerability Details" and at
least one subsection are checked by navigating to the Display tab, in the "Edit Scan Report Template"
window, and looking under "Include the following detailed results in the report."
• Qualys VMDR: a Tool Connector.
• Qualys CS: .csv of "images" or "container" scans.
• SCAP: .xml file containing the SCAP tool's scan results.

Threat Modeling Tools

Software Risk Manager supports the following Threat Modeling tools and import formats:

• IriusRisk: a Tool Connector.

• Microsoft Threat Modeling Tool 2016: .htm reports and .tm7 files. Note: .htm reports will include
images of the diagram and interaction for each finding.
• SD Elements: a Tool Connector.

Component Tools
Software Risk Manager supports the following Component tools and import formats:

• Black Duck Binary Analysis: a Tool Connector, .csv and .json is supported.
• Black Duck SCA: When Scan Farm is configured, Black Duck is available as a built-in tool. Also
accessible as a Tool Connector.
• Checkmarx One: a Tool Connector.
• Checkmarx OSA: a Tool Connector.
• Dependency-Check is a built-in scanner; .xml is also supported.
• Dependency-Track a Tool Connector.
• Dynatrace: a Tool Connector (Vulnerability data with no related container images only).
• GitHub Advanced Security (Dependabot) a Tool Connector.
• GitLab Security: .json and Report .zip.
• HCL AppScan on Cloud (ASoC): .xml and a Tool Connector.
• JFrog Xray: a Tool Connector, .json is supported
• Mend: a Tool Connector.
• NeuVector: a Tool Connector.
• Orca Security: a Tool Connector.
• Polaris: a Tool Connector.
• Retire.js is checked by Dependency-Check; if run externally, .json is supported.
• Snyk Open Source: a Tool Connector, .json is supported.
• Snyk License Compliance Management: a Tool Connector, .json is supported.
• Sonatype Nexus: a Tool Connector.
• Veracode: .xml and .zip. Additionally, Veracode is a Tool Connector.
• WhiteHat: a Tool Connector.
• WPScan: .json.

207
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Container Tools
Software Risk Manager supports the following Container tools and import formats:

• Anchore: a .json file generated using anchore-cli image vuln {image-name} all.
• Aqua Enterprise: a Tool Connector.
• Check Point CloudGuard: a Tool Connector (Vulnerability data only).
• Dynatrace: a Tool Connector (Vulnerability data with related container images only).
• GitLab Security: .json and Report .zip.
• Grype: a .json file with container image/filesystem results.
• Harbor: a .json or .csv Harbor vulnerability report.
• NeuVector: a Tool Connector.
• Orca Security: a Tool Connector.
• Snyk Container: a Tool Connector, .json is supported.
• Prisma Cloud Compute (Twistlock): a Tool Connector, a .json file generated with twistcli, or
one of the downloadable Twistlock CSVs in the Images, Scans, or Hosts format (the Connector is
strongly recommended); please see the Twistlock Support section for more information.
• Trivy: a .json file with container image results (other scan types are not yet supported).

Cloud Infrastructure Tools

Software Risk Manager supports the following Cloud Infrastructure tools and import formats:

• Prisma Cloud (RedLock): a Tool Connector (Alert data only), a .csv file of Alerts downloaded from
Prisma Cloud UI, or a .json file from the Prisma Cloud REST API "List Alerts V1" endpoint.
• AWS Security Hub: .json and a Tool Connector.
• Azure Security Center: a .csv file by clicking 'Download CSV report' from the 'Recommendations'
page in Microsoft Defender for Cloud.
• Check Point CloudGuard: a Tool Connector (Posture Finding data only).
• Wiz: a Tool Connector.
• Microsoft Defender for Cloud: a Tool Connector.

Bug Bounty Tools

Software Risk Manager supports the following Bug Bounty tools and import formats:

• Hacker One: a Tool Connector.

Infrastructure as Code (IaC) Tools

Software Risk Manager supports the following Infrastructure as Code tools and import formats:

• Checkmarx One: a Tool Connector.

• Checkov: .json.

208
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Orca Security: a Tool Connector.

Web Application Firewall (WAF) Tools

Software Risk Manager supports the following Web Application Firewall tools and import formats:

• Imperva: a Tool Connector.

Security Technical Implementation Guide (STIG) Tools

Software Risk Manager supports the following STIG tools and import formats:

• STIG: .ckl format checklist results exported by any common STIG tool.

AppDetective Pro
When generating a Check Results Report in AppDetective Pro, you will be given options for which fields to
include. For best results, we recommend including every field. However, at a minimum, the following fields
are required:

• Check Category
• Summary
• Overview
• Fix Information
• CVE
• References
• Links
• Vulnerability
• Description
• Show Occurrences

If any of these required fields are excluded, you will receive an error when uploading the report to Software
Risk Manager and analysis of the file will not be allowed.

AppSpider
Software Risk Manager accepts the VulnerabilitiesSummary.xml file from AppSpider. This file is
output as part of the report generation process within AppSpider.
To generate a report and locate the summary XML file:

1. Run a new scan or open an existing scan in AppSpider.

2. Generate a report by clicking the Generate Report button on the scan toolbar.
3. Locate the generated report on disk (the default location is Documents/AppSpider/Scans).
The VulnerabilitiesSummary.xml file in the report folder is the file that should be uploaded to

209
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Software Risk Manager for analysis.

Aqua SaaS Configuration

Software Risk Manager supports Aqua SaaS Configuration. For more information, click here.

CodeSonar
The preferred means of importing CodeSonar result into Software Risk Manager is to use the CodeSonar
Tool Connector. However, in situations where the machine running Software Risk Manager and the
machine running CodeSonar cannot communicate with each other, the CodeSonar-Scrape utility can
bridge the gap.
CodeSonar-Scrape is a command-line utility that you can use to generate a Zip file that Software Risk
Manager understands as CodeSonar results. You provide it the URL of your CodeSonar server, the name
of the project you want to import into Software Risk Manager, and optionally your username and password.
SRM will find all of the "warnings" associated with that project and download them into a Zip file, which you
can then upload to Software Risk Manager. Results imported in this manner will include descriptions
(tracing) information and links back to CodeSonar's hub for warning details and category documentation.
Detailed instructions for this tool can be found in the CodeSonar-Scrape User Guide. If you need
CodeSonar-Scrape or have questions, please contact us.

Dynatrace
Software Risk Manager supports data ingestion via the Dynatrace Tool Connector.
Connector authentication is performed with an access token. The user should have both the Read
security problems and Read attacks scopes for this token.

Helix QAC
Software Risk Manager supports the importation of Helix QAC rule compliance reports (.csv). The
instructions below show how to use the Helix QAC GUI to create a rule compliance report on your local
machine that you can upload to SRM.
To generate a rule compliance report from the Helix QAC GUI:

1. Click Report from the main menu and use the dropdown list to select which project or files to use.
2. Click the "Report Type" field and select "Rule Compliance Report" from the dropdown list.
3. Confirm the output location and the name of the report in the location and name fields.
You can either use the default settings or enter new values in the respective fields.
4. Click OK.
The report will be generated and placed in the selected output folder.

You can now upload the Helix QAC rule compliance report to SRM.

210
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information about Helix QAC, visit Perforce.com.

JFrog Xray Support

Software Risk Manager imports results from JFrog Xray using its built-in Reports feature, which does not
include a list of the scanned artifacts. This may cause resolved vulnerabilities to still appear in SRM. For
more information, click here.

Parasoft Support
Software Risk Manager accepts the XML SATE reports generated by Parasoft tools, which can be
generated using both the GUI and CLI. For more information, click here.

Prisma Cloud Compute (Twistlock)

Software Risk Manager supports data ingestion via the Prisma Cloud Compute (Twistlock) Tool Connector
and CSV/JSON files. The tool connector is strongly recommended due to limitations in CSV export1 and
JSON ingest2.
Connector authentication is performed with a username and password. The user should have the
monitorImages (Compute -> Monitor) permission at a minimum. The recommended built-in role is
DevSecOps. The connector will validate that the given user has the necessary permission during
configuration.
The connector offers several options for filtering images. Verifying any of these options will state the
number of images matched. This result is based only on the filter being verified. During analysis, all filters
will be combined.
The connector may ingest vulnerabilities from Deployed, Registry, and CLI image scans. Each particular
image type can be toggled during configuration. Filters will be applied to all selected scan types, where
applicable. Not all filters can be applied to CLI image scans. Fields inapplicable to CLI images will be noted
in their descriptions within the connector configuration page.
1
Downloading CSVs from the Prisma Cloud Compute UI will not download all results, only those visible on
the current page. Full CSVs can be downloaded by interacting with the REST API at api/v1/images/
download, which requires a separate API authentication step against api/v1/authenticate.
(Navigating to this endpoint with a browser will typically fail, regardless of authentication within the Prisma
UI.)
2
Analyzing JSON results in Software Risk Manager will archive any previous Twistlock JSON results as a
standard part of archival behavior. If multiple images are being scanned with Twistlock, the scans for all
images must be uploaded together in order for all of their results to persist after analysis.

Base Image Scanning

Twistlock allows filtering (exclusion) of base image vulnerabilities when retrieving results, which is exposed
as the option "Exclude base image vulns" in the connector config page.

211
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: Twistlock requires the base image to be in one of its configured registries, and the base image
must have been previously scanned:

To define your base images, go to Defend > Vulnerabilities > Images > Base images. The base images
you define must reside in your registry and they must be scanned to exclude their vulnerabilities from scan
reports.

Missing Image Data

Twistlock may temporarily report image data as "missing," even though it may reappear in subsequent
analyses. Results for these images will be missing once the analysis completes. Such missing data will be
reported as a warning on the Analysis page and in the Visual Log.

SARIF
Software Risk Manager strictly supports the v2.1.0 SARIF spec as outlined here and detailed here. New
formats will be added explicitly; support for v2.1.0 does not imply support for v2.1.1, and so on.

Note: All ingested SARIF results will be detected as "SAST," regardless of whether a "Container
Analysis" tool generated it.

Limitations
Software Risk Manager support for SARIF currently does not include the following notable features:

• External properties files

• Inline external properties
• JSON pointers/SARIF-URI schemes
• Suppressions
• Text/code/artifact snippets
• Localization data
• Details of tool/converter invocation
• Version control "provenance" information
• Location references to binary files
• Graph information
• Stack traces
• Tool notifications

Results with Multiple Locations

SARIF results containing multiple locations will be split into duplicate results, one for each location. If
multiple codeFlows are specified and none have a sink matching the result location, the codeFlow sinks
will be treated as the effective locations, and the result will similarly be split. This may cause a mismatch

212
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

between the location reported by the SARIF result and the location used by Software Risk Manager.

SBOM Files
Software Risk Manager supports the following SBOM import formats:

• CycloneDX: .xml and .json

• SPDX: .spdx and .json

Note: Uploading and analyzing SBOM files will not result in any new findings. The purpose of importing
SBOM files is to provide a single place to retrieve SBOMs and to store them.

Aqua SaaS Configuration

For Aqua Enterprise on-prem deployment, the connector only requires giving credentials for an Aqua user
with the necessary permissions. However, in an Aqua SaaS instance, the process of getting the necessary
credentials for the connector is more complicated. In this case, Aqua SaaS requires creating a permission
set, role, and an access token, as shown below.
To prepare credentials for the connector:

1. Log into cloud.aquasec.com.

2. Create a permission set:
a. Click the applications icon located in the top left corner and select Account Management from the
dropdown menu.

b. Select User Management > Permission Sets from the left menu.

213
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

c. Click "Add Permission Set" and enter a name in the Name field.
d. Expand the Assets category, locate "Images," and enable "view" by clicking the corresponding
icon.
This is needed for access to images.

e. Expand the Compliance category, locate "Vulnerabilities," and click the view icon.
This is needed for access to vulnerability reports on a finer, per-image-layer basis.

Note: (Optional) SRM will detect when this permission is unavailable and alter its logic
appropriately.

f. Click Save.
3. Create a role and assign the previously created permission set:
a. Select User Management from the left navigation menu and click Roles.
b. Click Add Role.
c. Enter a name in the Name field, select a permission set, and select an application scope.
d. Click Save.
4. Create an API Key:
a. Select Settings from the left navigation menu and click API Keys.
b. Click Generate Key and save the API Key and Key Secret.
c. Click the configuration icon to the right of the new API Key and select Edit.
d. Disable "Global Permissions."
e. Enable "roles:assign", "tokens:readwrite", permission (needed to authenticate with token).

Note: For "tokens:readwrite", give it permission to use the role created previously.

f. Click Save.

The role name from step 3 is used for the “Role Names” connector form field. The API Key and Key Secret
from step 4 are used in the “API Key” and “API Key Secret” connector form fields.

JFrog Xray Support

214
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Software Risk Manager imports results from JFrog Xray using its built-in Reports feature, which collects a
list of vulnerabilities for all scanned artifacts that match the specified filters. While this data includes the list
of vulnerabilities and the affected artifacts, it does not include a list of the scanned artifacts.
If a new version of an artifact is uploaded and scanned by JFrog Xray, and if it is found to have zero
vulnerabilities, that artifact may not have any entries in the report and vulnerabilities from older versions of
the artifact may still be present. While SRM does track the list of affected artifacts through the "JFrog
Impacted Artifacts" field on individual results, the existence of findings in the scanned project gives a false
impression of its state and makes it harder to tell which vulnerabilities are still present in the most recent
artifacts of interest.
Requests by SRM for the Build report type automatically include a filter to only fetch results for the latest
build. However, Repository reports do not have this option, which necessitates detection and filtering by
SRM to determine the latest version and its associated results.
When the JFrog Xray connector is configured to use Repository reports, SRM can perform a variety of
additional checks to discover the most recent version of each affected artifact. The types and number of
checks done will depend on which options are selected in the connector configuration form.

Detecting the "Latest Version"

The strategy for detecting the "latest version" depends on the "Latest Version Search Method" dropdown
field, which has the following options:

• None. All results from the report are ingested.

• Report Only. Finds the most recent artifact versions present in the Xray report.
• Active Search. Uses the JFrog Xray API to find the most recent version of each affected artifact.

The "None" option may be used if you are interested in vulnerabilities across all versions of the affected
artifacts. The "Report Only" option may be used if you expect the scanned artifacts to always contain at
least some vulnerabilities. The "Active Search" option may be used if you expect at least some scanned
artifacts to be completely free of vulnerabilities.
When a "latest version" is detected, its artifact ID and file path are recorded and used as a filter on the list
of vulnerabilities in the JFrog Xray report.

Finding the "Latest Version" within a Report

When using the contents of the Xray report to detect the most recent version, SRM will take each affected
artifact ID and split it on its last : (colon) character. Text up to this character will be used as the package
ID, and text after that character will be used as the package version.

Note: This logic is also used to filter for specific versions when "Version Filtering Mode" is set to "Text
Pattern."

SRM will take each artifact ID, its file path, and scan time for the artifact, and group this information
together based on the parsed package ID. For each group, the entry with the most recent scan time will be

215
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

used as the "latest version" for the given package ID.

Finding the "Latest Version" via JFrog Xray API

When using the Active Search method, SRM will use the Scans List - Get Package Versions API to find the
most recent version for each affected artifact. This requires detecting the correct package ID for the
artifact, which is the most time-intensive part of this process.
For each file name found in the JFrog Xray report, SRM will make a request to the Scans List - Get
Artifacts API, filtering to the file name and a creation time of ±1 hour of its scan date. If an entry is found
with a matching file path, it will be associated with the entry's packageId for later reference.
For any artifacts whose package ID was not resolved, SRM will create a set of "candidate" package IDs
based on the artifact ID. While JFrog artifact IDs do have a standard format, it's not guaranteed that the
IDs will be "fully formed." For example, there may be an RPM artifact with an artifact ID of rpm://7:rpm-
python:7:4.11.3-43.el7, or it may present the artifact as rpm://rpm-python:4.11.3-43.el7
depending on the Artifactory configuration. The candidate package IDs for an artifact ID will be
permutations of a subset of the artifact ID, for example 7:rpm-python:7, rpm-python:7, rpm-
python.
SRM combines the list of known package IDs and candidate IDs and uses the Get Package Versions
API for each package ID. SRM collects pages of package versions and, for each artifact associated with
the tested package ID, checks for an API response which matches the artifact ID and file path. This
ensures that SRM is reading from the correct list of package versions for a given artifact. SRM will collect
these pages until all associated artifacts are resolved, or the received versions are older than the oldest
artifact associated with the tested package ID. For artifacts that were matched, their latest version is set to
the most recent entry from the beginning of the list of versions provided by the JFrog Xray API.
SRM continues querying for package versions of each potential package ID, updating its list of associated
unresolved artifacts, until a latest version is discovered for all artifacts or all options are exhausted. For
remaining artifacts that have a known package ID but an unresolved version, SRM uses the scan date
from the JFrog Xray report to find the most recent version. For artifacts with an unresolved version and do
not have a known package ID, their results will be included without filtering.
This process gives SRM an updated list of "latest artifacts" to filter by. SRM then reads the JFrog Xray
report and only ingests results for artifacts whose artifact ID and file path exist in this list.

Optimization Options for "Active Search" Detection

The Active Search detection method attempts to ensure that the latest detected version is correct. This can
involve many requests to the JFrog Xray API and significantly lengthen analysis times. You can use the
"Latest Version Search Optimizations" dropdown field to let SRM make certain assumptions, which will
reduce the amount of API requests to JFrog Xray. This field has the following options:

• Accurate. The full search process is performed as previously described.

• Pre-Filter. SRM will use the "Report Only" filtering before making any API requests, reducing the
number of requests to Get Artifacts and, potentially, Get Package Versions.
• Optimistic. In addition to the Pre-Filter optimization, this option assumes that each package ID
candidate is a match for each associated artifact (without confirming their existence in the list of

216
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

package versions) and immediately returns the first package version in the list. This reduces the
number of requests to Get Package Versions.

It is typically safe to enable "Optimistic" filtering for the following package types:

• Docker
• Maven
• NPM
• Go
• Composer
• NuGet
• PyPi
• Conan

It is recommended to start with the "Accurate" optimization to get a baseline set of results and confirm that
other optimization options are consistent with that baseline.

Parasoft Support

Software Risk Manager accepts the XML SATE reports generated by Parasoft tools, which can be
generated using both the GUI and CLI.

Generating a Report from the GUI

To generate the report from the GUI:

1. Run a scan.
2. Click the Test Progress summary tab and click the Generate Report button in the toolbar.
The Report and Publish dialog will open.
3. Click Preferences.
4. Click the Format dropdown and select XML SATE (Static Analysis Tool Exposition).
5. Click Apply, then click OK.
The Report and Publish dialog will open.
6. Select the option to open the report in a browser.
7. Click OK.
The generated report will appear above the Test Progress and summary tab; the location of the file on
disk will display in the report tab.

Generating a Report from the Command Line Interface

To generate a report from the CLI and export the findings:

1. Create a file containing the proper report preferences, one setting per line.
The file must contain at least these settings:

217
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• report.custom.extension=xml
• report.format=sate
2. Select Parasoft -> Preferences from the toolbar.
3. Select Parasoft (root).
4. Click the "share" link in the "Configure settings" section.
5. Enter the filepath into the text box.
This will be where your settings file will be located.
6. Check the "Reports" option, then click OK.
7. Run the CLI with the following options:
• -localsettings path/to/settings/file
• -report path/where/report/should/go/filename.xml
The report to upload to Software Risk Manager will be at path/where/report/should/go/
filename_report.xml or path/where/report/should/go/filename_sate.xml

SonarQube Support

When using SonarQube, there are two potential issues to be aware of. The first deals with permissions;
the second, listings.

Permissions
Non-admin tokens may see permission-related issues when importing projects or when running analyses.
SRM performs permission checks during project import to prevent the selection of items that cannot be
accessed. Consequently, you should note the following:

• These checks can greatly extend the runtime of project auto-import through the Integrations page.
• The additional requests can cause rate-limiting errors when accessing SonarQube.
• Projects that are successfully imported may later see analysis errors if the token has some permissions
revoked at a later time.

However, if you are using an admin token, you can set sonarqube.permission-checks.enabled =
false in the SRM props file to disable these permission checks during project import. (This will not affect
permission checks done during analysis.)

Listings
SonarQube has an internal limit of 10,000 items when listing any sort of data from their API. This affects
lists of projects, bugs, hotspots, and so on.
When listing projects, SRM will stop once it reaches this internal limit, which can prevent some projects
from appearing. However, if an admin token is provided, SRM will use an alternative method that will
bypass the 10,000 project limit, allowing SRM to show the full list of projects. Note: This ability to bypass
the project limit does not apply to any other data requested from SonarQube.
When listing issues during analysis, SRM mitigates this limit by using specific lists like “critical bug issues
in project X” instead of larger lists like “all issues in portfolio Y.” Nevertheless, it’s still possible for these

218
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

“specific” lists to exceed the 10,000 project limit, in which case analysis will fail with an error.

Starting an Analysis

There are several ways to prepare and initiate an analysis with Software Risk Manager.
For detailed instructions on running an analysis, click one of the links below:

• Using the web interface

• Using the API
• Starting an analysis with Black Duck Bridge CLI

Starting an Analysis Using the Web Interface

Analyses can be prepared and initiated manually from the Software Risk Manager web interface.

Note: To start an analysis, you will need a defined project and a current analysis configuration.

To start an analysis:

1. Click the Projects icon on the navigation bar to open the Projects page.
2. Click the project's dropdown configuration icon and select New Analysis.
3. Select a target branch from the Target Branch dropdown menu.
You can choose an existing branch or create a new one by typing a new (unique) name into the branch
field. Entering text will also filter the existing branch names.
4. Click Add File to upload files for analysis.
As you add files, they will be uploaded to the SRM server for identification. Once the server has
identified the file contents, SRM will display the following information:
• Detected Content
• Tools to Run
Use the checkbox on the tag to disable (or re-enable) that tag. Disabling a tag in the Tools to Run
section will tell SRM not to run that tool, even though it is applicable to that file.
5. Click Begin Analysis.
Analysis is conducted as a "job." The work order is placed in the job queue and will be executed once
enough resources are free. Often, the time spent in the queue is negligible, but you might still see a
message stating that the analysis has been queued. Once the analysis job is finished queueing, the
analysis will begin. The page will display a timer to indicate the current duration of the analysis.

The actual duration of the analysis depends on several factors, including the following:

• How big is your application? An application's size is likely the most significant factor in determining the
duration of an analysis. Smaller apps usually take around 30 seconds, medium-size apps can take tens
of minutes, and large apps can take hours or more.
• Is Software Risk Manager running tools for you? If so, the analysis duration will include the time it takes
to run these tools. The time it takes to run a tool on your application will usually grow as your

219
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

application grows.
• How much activity is going on in Software Risk Manager? More activity by users of Software Risk
Manager means more load on the database, which can slow down analysis to some degree.
• How many findings can be discovered? This is difficult to know ahead of time, but the number of tool
results/findings in a project will also affect the analysis duration. In this manner, a small application with
many vulnerabilities might take longer to analyze than a large application with very few vulnerabilities.

Once the analysis has been queued, it is safe to leave the page. The analysis will continue in the
background. Keep the page open, however, is recommended in order to see any warnings or errors that
might occur during the analysis.
If the analysis completes successfully, the analysis timer will become a link to the Findings page. Any
currently-opened Findings pages will be updated to reflect the latest analysis results.

Deploying Intelligent Orchestration

If your Software Risk Manager implementation includes Intelligent Orchestration (IO), applying an IO policy
to a project will generate prescriptions for the best tools to use in analyzing the code. Those prescribed
tools will be automatically selected in the Tools to Run section of the New Analysis page. For more
information on Intelligent Orchestration, see Intelligent Orchestration.

Inputs from Git Repositories

If you set up a Git Configuration for a project, the New Analysis page will automatically include the latest
contents of the configured branch of the configured repository as an input.
Normally, Software Risk Manager will update the local clone and check out the appropriate branch before
sending the files to the analysis. As development is done on that branch, analysis of that branch will
change along with the contents. But if you want to analyze a specific point in the repository, you can
configure Software Risk Manager to use a specific branch, commit, or tag by clicking on the underlined
section of the input. Select the branch, commit, or tag and click Use this.

Starting an Analysis Using the API

Software Risk Manager offers an expanding API to interface with the system's functionality
programmatically. The ability to push files for an analysis by Software Risk Manager is exposed by the API.
This enables automated integration scenarios such as continuous integration. In a continuous integration
scenario, a post-build step can be added to the build jobs to automatically push the source and compiled
artifacts to Software Risk Manager for analysis. This type of setup is strongly recommended for
development teams to catch potential issues within their codebases early for quick remediation. (Software
Risk Manager offer a Jenkins plugin to facilitate use in a continuous integration context.)
Before an API key can be used for automated analyses, the key must be assigned the create role for the
project. The API call to push the files and initiate the analysis is documented in the Software Risk Manager
API Guide.

Tool Orchestration

220
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

When the Tool Orchestration Service is enabled, Software Risk Manager can orchestrate analyses that run
in whole or in part on your Kubernetes (k8s) cluster. (See the Tool Orchestration Configuration section in
the Software Risk Manager Install Guide for instructions to enable this feature.)
A Software Risk Manager analysis may run one or more built-in code scanners. Many of those tools can
run on your Kubernetes cluster when you enable the tool orchestration feature. Those that cannot, such as
Dependency Check, will continue to run on the Software Risk Manager web server.
The following table shows which bundled tools Software Risk Manager can run on your k8s cluster.
Table 1.
Bundled Tool Tool Orchestration Support
Brakeman Yes
CheckStyle Yes
CPPCheck Yes
DependencyCheck No
ESLint Yes
FxCop (user-installed) No
Gendarme Yes
JSHint Yes
PHP Code Sniffer Yes
PHP MD Yes
PMD Yes
Pylint Yes
Retire JS No
ScalaStyle Yes
SpotBugs Yes
ZPA CLI Yes

Software Risk Manager also includes the following tool orchestration capabilities that run only on your k8s
cluster:

• Checkmarx
• Security Code Scan
• ZAP

A single Software Risk Manager analysis can have tools running on both the webserver and on multiple
nodes of your k8s cluster. All tool outputs will be combined into one analysis that either succeeds or fails
as a whole, provided the Software Risk Manager web server remains online throughout the analysis.
If the Software Risk Manager web application unexpectedly restarts, a built-in fail-safe lets Software Risk
Manager receive k8s analysis results from abandoned orchestrated analyses. Software Risk Manager will
lose any results from bundled tools in this case, so a restart of the Software Risk Manager web application

221
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

is one scenario where Software Risk Manager may process results from a partially completed analysis.
When Software Risk Manager detects an orchestrated analysis that it is not tracking, a message will
appear on the Orchestrated Analyses page.
You can configure Software Risk Manager to run additional tools by implementing other add-in tools.
For additional information, see the following sections:

• Resource Requirements
• Scanning a Request File
• Adding a Tool

Resource Requirements

When the Tool Orchestration Service is enabled, Software Risk Manager can create orchestrated analyses
that run one or more application security testing tools where each tool has access to its host's memory and
CPU resources. Using Kubernetes (k8s) tools, you can control the memory and CPU capacity available to
analyses. You can also improve k8s scheduling outcomes by requesting CPU or memory capacity for
specific tools or projects. Resource requirements can also include a node selector and pod toleration, with
taint effects NoSchedule and NoExecute, to influence further where tools run on your cluster.
The resource requirements feature cannot be configured using the Software Risk Manager user interface,
but you can use the k8s kubectl command to define configuration maps (configmaps) that cover specific
scope determined by a special naming convention. The tool service will look for and read optional
configmaps to determine how resource requirements apply to a specific tool run.
Resource requirements containing CPU and memory instructions translate to k8s resource requests and
limits and fit with any other related k8s configuration, such as a resource limit defined for a k8s
namespace. You can specify resource requirement data by using the following configmap field names:

• requests.cpu – k8s CPU request (e.g., 1).

• requests.memory – k8s memory request (e.g., 1G).
• limits.cpu – k8s CPU limit (e.g., 2).
• limits.memory – k8s memory limit (e.g., 2G).
• nodeSelectorKey – key portion of a label associated with a node selector (e.g., purpose).
• nodeSelectorValue – value portion of a label associated with a node selector.
• podTolerationKey – key portion of a taint with the NoSchedule and NoExecute taint effects (e.g.,
dedicated).
• podTolerationValue – value portion of a taint with the NoSchedule and NoExecute taint effects (e.g.,
tools).

There are four types of configmaps that can contain resource requirements:

• Global
• Global Tool
• Project
• Project Tool

Software Risk Manager deployment creates the Global Resource Requirement, which provides default
resource requirements for tools across every Software Risk Manager project. Global Tool requirements
override Global requirements for specific tools. Project requirements override both Global and Global Tool

222
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

requirements by providing default resource requirements for tools associated with a given project. And
Project Tool requirements override other requirements by specifying values for a specific tool in a specific
project.

Scope Overlap
The following is an example of how the scopes can overlap:
Global Resource Requirement:

• CPU Request = 1
• CPU Limit = 4
• Memory Request = 11G
• Memory Limit = 12G

Global Tool Resource Requirement:

• CPU Request = 3

Project Resource Requirement:

• Memory Request = 13G

Project Tool Resource Requirement:

• Memory Limit = 14G

Here are the effective resource requirements resulting from the above:
Effective Resource Requirement:

• CPU Request = 3
• CPU Limit = 4
• Memory Request = 13G
• Memory Limit = 14G

The naming convention determines the scope of a resource requirement configmap:

• Global: cdx-toolsvc-resource-requirements
• Global Tool: cdx-toolsvc-ToolName-resource-requirements
• Project: cdx-toolsvc-project-ProjectID-resource-requirements
• Project Tool: cdx-toolsvc-project-ProjectID-ToolName-resource-requirements
where ProjectID is the integer value representing the Software Risk Manager project identifier and
ToolName is the tool name converted to an acceptable k8s resource name by the following rules:
• Uppercase letters must be converted to lowercase.
• Any character other than a lowercase letter, number, dash, or period must be converted to a dash.
• An initial character that is neither a number nor a lowercase letter must be preceded by the letter "s."
• A name whose length is greater than 253, must be truncated to 253 characters.

223
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Example 1 - Project Resource Requirement

To create a resource requirement for all tool runs of a Software Risk Manager project represented by ID
21, create a file named cdx-toolsvc-project-21-resource-requirements.yaml and enter the
following data:

apiVersion: v1
kind: ConfigMap
metadata:
name: cdx-toolsvc-project-21-resource-requirements
data:
requests.cpu: "1"
limits.cpu: "2"
requests.memory: "1G"
limits.memory: "2G"

Note: You can find a project's ID at the end of its Findings page URL. For example, a project with the ID
21 will have a Findings page URL that ends with /srm/projects/21.

Run the following command to create the configmap resource (replacing the cdx-svc k8s namespace, if
necessary).

kubectl -n cdx-svc create -f ./cdx-toolsvc-project-21-resource-requirement

s.yaml

Example 2 - Global Tool Resource Requirement

To create a Global Tool resource requirement for ESLint, create a file named cdx-toolsvc-eslint-
resource-requirements.yaml and enter the following data:

apiVersion: v1
kind: ConfigMap
metadata:
name: cdx-toolsvc-eslint-resource-requirements
data:

224
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

requests.cpu: "2"
limits.cpu: "3"
requests.memory: "4G"
limits.memory: "5G"

Run the following command to create the configmap resource (replacing the cdx-svc k8s namespace, if
necessary).

kubectl -n cdx-svc create -f ./cdx-toolsvc-eslint-resource-requirements.yaml

Example 3 - Node Selector

To create a Global Tool resource requirement for running a tool named MyTool on cluster nodes labeled
with canrunmytool=yes, create a file named cdx-toolsvc-mytool-resource-
requirements.yaml and enter the following data:

apiVersion: v1
kind: ConfigMap
metadata:
name: cdx-toolsvc-mytool-resource-requirements
data:
nodeSelectorKey: canrunmytool
nodeSelectorValue: yes

Run the following command to create the configmap resource (replacing the cdx-svc k8s namespace, if
necessary):

kubectl -n cdx-svc create -f ./cdx-toolsvc-mytool-resource-requirements.yaml

Scan Request File

An add-in tool is based on a scan request file that you define and register with Software Risk Manager. A
scan request file contains the instructions that the tool service needs to invoke an application security
testing tool on the k8s cluster and ingest its output into Software Risk Manager. Scan request files use the
TOML file format. You can specify any valid TOML content in your tool's scan request file provided you
specify the request table, which is a reserved section with the following parameters.

225
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
Key Description Required?
imageName The name of the Docker image containing your add-in tool Yes
workDirectory The work directory where your add-in tool can find tool inputs Yes
shellCmd The Bourne shell command to invoke your add-in tool Yes
resultFilePath The output of your add-in tool Yes
logFilePaths An array of log files produced by your add-in tool No
preShellCmd An optional command to run prior to invoking the shellCmd No
postShellCmd An optional command to run after invoking the shellCmd No
securityActivit The Intelligent Orchestration security activities supported by this tool
No
ies (e.g., sca, sast, dast)

A tool run ends in an error when either shellCmd, preShellCmd, or postShellCmd return a non-zero exit
code. When the tool service runs an add-in tool, it creates the following directory structure at the path
specified by the value of the workDirectory key.
Table 2.
Content Description
A directory containing zero or more certificates that should be considered
/ca-certificates
trusted certificate authorities
/config/ A copy of the tool's scan request file, including any project-specific
request.toml configuration
/input A directory containing an optional input file
/volume-secret A system directory required for storing tool outputs
Zero or more workflow secrets associated with an add-in tool's project
/workflow-secrets
configuration

When the tool service invokes an add-in tool, it provides the tool with a copy of its scan request file, so the
file is a convenient place to store configuration data. After you register an add-in tool, Software Risk
Manager lets you edit TOML content outside the request table on a per-project basis, so you can have
key values that vary by project. For example, a DAST tool might have a scan request file with a key whose
value indicates the URL from which to start a scan; the URL can vary from one Software Risk Manager
project to the next.

Adding an AppSec Testing Tool

You can add an application security testing tool to the list of tools that Software Risk Manager can run on a
Kubernetes cluster by completing the following tasks:

1. Implement a command/script/application that automates a tool.

226
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

2. Package the capability into a Docker image that can be invoked from a Bourne shell.
3. Define a scan request file, specifying (at a minimum) the key values of the Software Risk Manager
request table.
4. Register the add-in tool.
5. Enable the tool for specific projects, configuring any project-specific key values defined in the scan
request file.

This walkthrough will show you how to create, register, and enable an add-in tool that automates Security
Code Scan, a static code analysis tool for .NET. The Security Code Scan add-in tool is automatically
installed when you enable the Software Risk Manager Tool Orchestration feature, but you can use this
walkthrough to learn how to add a new add-in tool whose output must be transformed to the Software Risk
Manager XML Schema.

Tool Automation
Your first task will be to create a PowerShell Core script that can automate Security Code Scan. We will
use a script that defines two parameters: a path to an input archive containing C# source and a path to an
output file with findings that Software Risk Manager can ingest.
Create a directory called SecurityCodeScan. Download SecurityCodeScan.ps1 to the directory. The
PowerShell Core script you downloaded takes the following steps to automate Security Code Scan.

1. Unpack the source code in the input file provided by Software Risk Manager.
2. Add the SecurityCodeScan.VS2017 project reference to each source code project file.
3. Run dotnet build.
4. Translate the findings from the build results into the generic SRM XML format.

The last step is required because Software Risk Manager does not support ingesting Security Code Scan
findings directly. If you were automating Checkmarx, a tool whose output Software Risk Manager can read,
then Step 4 would be unnecessary. You will handle Step 4 with a separate script, so download
SecurityCodeScan-Results.ps1 to your SecurityCodeScan directory.

Tool Packaging
To package the Security Code Scan automation, you must create a Docker image capable of running both
PowerShell Core scripts and compilations of .NET Core 2 code. Adding PowerShell Core to a Docker
image based on microsoft/dotnet:2.2-sdk creates a suitable environment.
Download Dockerfile.txt to your SecurityCodeScan directory, and run the following command from that
directory to generate a Docker image that can automate Security Code Scan.

docker build -t codedx-securitycodescanrunner:v1.0 -f ./Dockerfile.txt .

Scan Request File

The docker build command from the previous section created a Docker image named codedx-

227
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

securitycodescanrunner:v1.0 that contains the SecurityCodeScanner.ps1 script in the /opt/

codedx/securitycodescan directory. The following scan request file content describes how to run
SecurityCodeScanner.ps1 on an input provided by Software Risk Manager.

[request]
imageName = "codedx-securitycodescanrunner:v1.0"
workDirectory = "/opt/codedx/securitycodescan/work"
shellCmd = '''
source=$(ls /opt/codedx/securitycodescan/work/input)
pwsh /opt/codedx/securitycodescan/script/SecurityCodeScan.ps1 \
"/opt/codedx/securitycodescan/work/input/$source" \
/opt/codedx/securitycodescan/work/output/securitycodescan.output.x
ml
'''
resultFilePath = "/opt/codedx/securitycodescan/work/output/securitycodesca
n.output.xml"
securityActivities = ['sast']

The value of the imageName key is codedx-securitycodescanrunner:v1.0, the Docker image you
created. The workDirectory key value is /opt/codedx/securitycodescan/work, a directory that already exists
because your Dockerfile established a /opt/codedx/securitycodescan/work/output directory to store the
result from SecurityCodeScan.ps1. Software Risk Manager uses the work directory to store add-in tool
data.
The shellCmd key value is the Bourne shell script Software Risk Manager will run to invoke your add-in
tool. SecurityCodeScan.ps1 requires two parameters: an analysis input file and an output file. Software
Risk Manager puts the analysis input file in the input directory, which is a sub-directory of the work
directory. The analysis input file parameter will come from a search of that directory, and the output file will
be /opt/codedx/securitycodescan/work/output/securitycodescan.output.xml. The
value of the resultFilePath key directs Software Risk Manager to the add-in tool output and will match the
script's output file parameter.
In this example, you did not use the optional scan request file keys. The logFilePaths key is unnecessary
because SecurityCodeScan.ps1 writes log information to stdout, and the shellCmd does not require any
pre or post commands that you could accomplish with preShellCmd and postShellCmd.

Note: securityActivities is used to define the add-in tool type for use in Intelligent Orchestration
implementations.

228
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Software Risk Manager Registration

Registering your add-in tool with Software Risk Manager is the next step. Log on to Software Risk
Manager as an administrator, click the Settings icon in the navigation bar, then select Add-In Tools from the
left menu.

Click Create New Tool to open the Add-In Tool Registration window.

229
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Click the New Tool label in the window title area, replace the text with a meaningful name, like Security
Code Scan, if that name is not in use, and click OK.
Security Code Scan is a SAST tool requiring an analysis input, so you must associate your add-in tool with
one or more types of content that Software Risk Manager can detect. Select Source Code for Tag type, C#
for Language, and click Add Tag so that Software Risk Manager will offer to run Security Code Scan
whenever it detects an analysis input file containing C# source. Lastly, specify the contents of your scan
request file in the TOML Spec section. Click Done to save your add-in tool registration.

Enable Add-In Tool

Your add-in tool is now registered in a disabled state. To enable your add-in tool for a specific project, open
the Tool Service Configuration page, find your add-in tool in the Customized Add-In Tools section, toggle
the Disabled/Enabled switch to enabled, and click Save. You can also use the Default enabled toggle to
enable a tool for every project, excluding those where it was explicitly disabled.
Below the Disabled/Enabled toggle is a box where you could edit any project-specific TOML content, which
is scan request file content outside the request section (Security Code Scan has none).

Software Risk Manager will offer to run enabled add-in tools whenever it detects an analysis input
containing C# source code in the project where you enabled the add-in.

230
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Users will have the option to deselect your add-in tool when they start a new analysis. For example,
Software Risk Manager does not distinguish between C# source code for .NET Core and .NET
Framework, and since your add-in tool runs on Linux, it supports .NET Core code only. A user configuring
a new analysis with .NET Framework source code (not .NET Core source code) could deselect your add-in
tool in that case.

Tool Status and Severity Mapping

Not all of the tools supported by Software Risk Manager report risk in the same way. For this reason, the
severity and status findings reported by each tool are converted or "mapped" to SRM risk ratings.
To see how each tool's findings are mapped, use the links below to locate the desired tool. Tools are
grouped according to type.

• SAST Tools Mapping

• DAST Tools Mapping
• IAST Tools Mapping
• Mobile Tools Mapping
• InfraSec Tools Mapping
• Threat Modeling Tools Mapping
• Component Tools Mapping
• Container Tools Mapping
• Cloud Infrastructure Tool Mapping
• Infrastructure as Code (IaC) Tool Mapping
• WAF Tools Mapping
• STIG Tools Mapping

SAST Tools Mapping

The tables below show the severity and triage status mappings for all of the SAST tools that are supported
by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

231
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Severity Mapping

232
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
SAST Tools Critical High Medium Low Info Unspecified
Correctness;
Correctness:
Usability,
Messages, Fatal;
Topography;
Correctness:
Usability, Icons;
Messages, Error; Correctness:
Usability;
Internationalization Messages
Android Lint1 Security
, Fatal; Warning,
Accessibility;
Internationalization
Internationalization Performance
, Warning; Bi-
, Error; Bi-
directional Text,
directional Text,
Warning
Fatal; Bi-directional
Text, Error
Armorize
HIGH MEDIUM LOW
CodeSecure
Brakeman
Checkmarx Info / 0, Unspecified,
4 High / 3 Medium / 2 Low / 1
(SAST) Information Unknown
Checkmarx One
CRITICAL HIGH MEDIUM LOW INFO
(SAST)
Checkstyle
Clang
Clang
CRITICAL HIGH MEDIUM LOW STYLE
(CodeChecker)
Clippy error warning note / failure-note help none
CodePeer high medium low

233
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SAST Tools Critical High Medium Low Info Unspecified

CodeSonar-
Red Yellow Green
Scrape2
performance,
CppCheck error portability, style information none
warning
Moderate /
Coverity Very High / Critical Major / High Minor / Low Audit, Very Low
Medium
Coverity On
critical high medium low audit
Polaris
42Crunch 5 4 3 2 1
DefenseCode
critical high medium low informational
ThunderScan
ErrCheck all
error-prone
ESLint
impact >= 2.5 and likelihood < 2.5
Fortify3 likelihood >= 2.5
impact >= 2.5 likelihood >= 2.5
and impact < 2.5
Fortify Software impact >= 2.5 and likelihood < 2.5
impact >= 2.5 likelihood >= 2.5
Security Center*** likelihood >= 2.5 and impact < 2.5
Gendarme
GitLab Security critical high medium low informational
GoCyclo all
GoLint
GoSec HIGH MEDIUM LOW
HCL AppScan critical high medium low informational

234
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SAST Tools Critical High Medium Low Info Unspecified

Source
HCL AppScan on
critical high medium low informational
Cloud (ASoC)
3 (Important
7 (Undefined 0 (Information), 1
issue), 4 (Local
behavior), 8 (Obsolete
Helix QAC criteria), 5 (Data 2 (Minor issue)
(Language message), 9
flow analysis), 6
constraints) (Error)
(Portability)
IneffAssign all
JLint
JSHint all
Microsoft Code
Analysis
dangerous, normal, signature,
MobSF medium, warning
insecure, high info, good
MobFS Scan ERROR WARNING INFO
NDepend Critical High Medium Low Info
OCLint
Orca Security
CRITICAL HIGH MEDIUM LOW INFO
(Secret Scans)
Level 1: Severe
Level 4: Possible
Parasoft JTest / Violation; Level 2:
Level 3: Violation Violation; Level 5:
C++Test / dotTest Possible Severe
Informational
Violation
PHPMD 1, 2 3 4, 5

235
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SAST Tools Critical High Medium Low Info Unspecified

PMD 1, 2 3 4, 5
Polaris critical high medium low informational
Pylint
Rapid Scan SAST critical high medium low informational
SafeSQL all
medium / note / info /
SARIF severe / critical high / error low / warning
moderate informational
SATE 1, 2 3 4, 5
Scalastyle
Scan@Source critical high medium low informational
SCARF
Semgrep high medium low
Snyk Code critical high medium low
SonarQube / BLOCKER /
MAJOR / HIGH MEDIUM MINOR / LOW INFO
SonarCloud CRITICAL
SpotBugs /
1 2 3
FindBugs
Staticcheck
Verified = true;
Verified = false Verified = false Verified = false
Verified = false
AND Detector AND Detector AND Detector
TruffleHog AND Detector
Name = Name = Generic Name =
name = Oauth,
PrivateKey Secret Unspecified
AWS, or Heroku
Veracode 4 3 2 1

236
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SAST Tools Critical High Medium Low Info Unspecified

Vet
WhiteHat (Legacy
urgent, critical high medium low informational, note
Rating System)
WhiteHat
(Advanced Rating Critical High Medium Low Note
System)

237
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. Android Lint evaluates risk based on both a category and a severity level. Categories are indicated by
an asterisk.
2. CodeSonar reports risk through a combination of a ranking formula and an analysis warning system
(red, yellow, green). Software Risk Manager uses the red, yellow, and green statuses to map to high,
medium, and low, respectively.
3. Fortify reports risk by creating scores for “impact” and “likelihood.” The combination of these scores is
then mapped to the Software Risk Manager severity levels.

Triage Status Mapping

238
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
SAST Tools Ignored False Positive To Be Fixed Mitigated Fixed Reopened
Android Lint
Armorize
CodeSecure
Brakeman
Checkmarx NOT_EXPLOITAB URGENT / 3;
False Positive
(SAST) LE / 1 CONFIRMED / 2
NOT_EXPLOITAB
Checkmarx One LE; URGENT;
(SAST) PROPOSED_NOT CONFIRMED
_EXPLOITABLE
Checkstyle
Clang
Clang false_positive,
intentional confirmed
(CodeChecker) suppress
Clippy
CodePeer not a bug false positive
CodeSonar-
Scrape**
CppCheck
Coverity Intentional, ignore False Positive
DISMISSED
Coverity On INTENTIONAL,
FALSE POSITIVE TO BE FIXED
Polaris DISMISSED
OTHER

239
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SAST Tools Ignored False Positive To Be Fixed Mitigated Fixed Reopened

42Crunch
DefenseCode
false positive
ThunderScan
ErrCheck
error-prone
ESLint
Exploitable,
Suppressed, Not Suspicious,
Fortify***
an Issue Reliability Issue,
Bad Practice
Exploitable,
Fortify Software Suppressed, Not Suspicious,
Security Center*** an Issue Reliability Issue,
Bad Practice
Gendarme
GitLab Security
GoCyclo
GoLint
GoSec
HCL AppScan
noise passed fixed reopened
Source
HCL AppScan on
noise passed fixed reopened
Cloud (ASoC)
Helix QAC

240
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SAST Tools Ignored False Positive To Be Fixed Mitigated Fixed Reopened

IneffAssign
JLint
JSHint
Microsoft Code
Analysis
MobSF
MobFS Scan
NDepend
OCLint
Orca Security
(Secret Scans)
Parasoft JTest /
C++Test / dotTest
PHPMD
PMD
dismissed (any dismissed (false
Polaris to-be-fixed
other reason) positive)
Pylint
Rapid Scan SAST
SafeSQL
SARIF
SATE
Scalastyle

241
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

SAST Tools Ignored False Positive To Be Fixed Mitigated Fixed Reopened

Scan@Source
SCARF
Semgrep fixed
Snyk Code ignored
SonarQube / ACKNOWLEDGE
WON'T FIX, SAFE FALSE POSITIVE FIXED REOPENED
SonarCloud D
SpotBugs /
FindBugs
Staticcheck
TruffleHog
Mitigate by Design,
Mitigate by
Potential False Reported to Library Network
Veracode Accept the Risk
Positive Maintainer Environment,
Mitigate by OS
Environment
Vet
accepted, out of
WhiteHat Invalid, false open, mitigated
scope

242
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

DAST Tools Mapping

The tables below show the severity and triage status mappings for all of the DAST tools that are supported
by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

243
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
DAST Tool Critical High Medium Low Info Unspecified
Acunetix Desktop high medium low info
INFORMATION
IMPORTANT,
Acunetix 360 CRITICAL MEDUIM LOW (BEST
HIGH
PRACTICE)
AppSpider Vulnerability
4 5 6 1, 0
Summary
APIsec Blocker, Critical Major, High Medium Minor, Low Info
Arachni high medium low informational
Burp Suite high medium low informational
Defensics fail warning
Dynatrace
HP WebInspect 4 3 2 1 0
HCL AppScan Standard
Critical High Medium Low Information
(enterprise)
HCL AppScan on Cloud
Critical High Medium Low Information
(ASoC)
Imperva* CRITICAL MAJOR MINOR
Invicti Standard Critical, Important, Information (Best
Medium Low
(formerly Netsparker) High Practice)
Invicti Enterprise
Information (Best
(formerly Netsparker Critical Important, High Medium Low
Practice)
Enterprise)
OWASP ZAP 3 2 1 0

244
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

DAST Tool Critical High Medium Low Info Unspecified

Polaris critical high medium low informational
Qualys WAS 5 4 3 2 1
Rapid7 InsightAppSec
Rapid7 InsightVM Critical Severe Moderate
Rapid7 Nexpose 8-...-10 4-...-7 0-...-3
Black Duck Managed
Critical High Medium Low Minimal
Services Platform
Tenable WAS blocker / critical major / high medium minor / low info
Tinfoil Web critical high medium low informational unknown
Trustwave App Scanner High Medium Low all other values
Veracode 4 3 2 1
note
WhiteHat urgent (critical) high low unspecified
(informational)
WPScan all
Sqlmap output all

245
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Triage Status Mapping

246
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
DAST Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened None
Acunetix Desktop
Acunetix 360 Accepted Risk False Positive Fixed
AppSpider
Vulnerability Summary
APIsec
Arachni
Burp Suite
Defensics
Dynatrace
HP WebInspect
HCL AppScan
noise passed fixed reopened
Standard (enterprise)
HCL AppScan on
noise passed fixed reopened
Cloud (ASoC)
Imperva*
Invicti Enterprise
(formerly Netsparker Accepted Risk False Positive Fixed
Enterprise)
OWASP ZAP
dismissed (any dismissed
Polaris to-be-fixed
other reason) (false positive)
Qualys WAS

247
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

DAST Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened None
unreviewed,
Rapid7 InsightAppSec ignored false positive verified remediated
duplicate
Rapid7 InsightVM
Rapid7 Nexpose
Black Duck Managed
False Positive
Services Platform
Tenable WAS
Tinfoil Web
Trustwave App
Scanner
Mitigate by
Design,
Reported to Mitigate by
Accept the Potential False
Veracode Library Network
Risk Positive
Maintainer Environment,
Mitigate by OS
Environment
accepted, out
WhiteHat Invalid, false open, mitigated
of scope
WPScan
Sqlmap output

248
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

*Imperva only produces severities for API Attack Analytics results and not for API Risks or WAF Security
Events. API Risk and WAF Security Event findings will only have Unspecified severity in SRM.

IAST Tools Mapping

The tables below show the severity and triage status mappings for all of the IAST tools that are supported
by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

249
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
IAST Tool Critical High Medium Low Info Unspecified
Checkmarx Unspecified,
Critical / 4 High / 3 Medium / 2 Low / 1 Informational / 0
(IAST) Unknown
Contrast Critical High Medium Low Note
HCL AppScan on
Critical High Medium Low Information
Cloud
NowSecure
Workstation
Q-MAST CRITICAL HIGH MEDIUM LOW
Black Duck
critical high medium low informational
Seeker

250
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Triage Status Mapping

251
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
IAST Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened
Checkmarx NOT_A_PROBLE
CONFIRMED REMEDIATED
(IAST) M
URL access limited
Confirmed or
Contrast or internal security False Positive Remediated
Suspicious
control
HCL AppScan on
noise passed fixed reopened
Cloud
NowSecure
Workstation
Q-MAST
Ignored / Won't Fix
Black Duck
/ Intentional, False Positive Fixed
Seeker
Archived

252
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

Mobile Tools Mapping

The tables below show the severity and triage status mappings for all of the Mobile tools that are
supported by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

253
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
Mobile Tool Critical High Medium Low Info Unspecified
Data Theorem
critical high medium low information
Mobile Secure
HCL AppScan on
Critical High Medium Low Information
Cloud (ASoC)
MobSF
MobSF Scan
NowSecure AUTO
NowSecure
INTEL
NowSecure
critical high medium low info unknown
Workstation

254
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Triage Status Mapping

255
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
Mobile Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened
Data Theorem
Mobile Secure
HCL AppScan on
noise passed fixed reopened
Cloud (ASoC)
MobSF
MobSF Scan
NowSecure AUTO
NowSecure
INTEL
NowSecure
Workstation

256
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

InfraSec Tools Mapping

The tables below show the severity and triage status mappings for all of the InfraSec tools that are
supported by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

257
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
InfraSec Tool Critical High Medium Low Info Unspecified
AppDetective Pro high medium low informational

Tenable Nessus1 4 3 or Cat I 2 or Cat II 1 0 or Cat III

Rapid7 Nexpose

NMap2 9+ 7-...< 9 4-...< 7 <4

Qualys VM 5 4 3 2 1
Qualys CS 5 4 3 2 1
SCAP High Medium Low Info
Qualys VMDR 5 4 3 2 1

258
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. Tenable Nessus reports risk through a "category" ranking (1-3) and a severity level (0-4).
2. NMap reports risk using a CVSS score.

Triage Status Mapping

259
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
InfraSec Tool Ignored False Positive Fixed Mitigated Fixed Reopened
AppDetective Pro
Tenable Nessus
Rapid7 Nexpose
NMap
Qualys VM
Qualys CS
SCAP
Qualys VMDR

260
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

Threat Modeling Tools Mapping

The tables below show the severity and triage status mappings for all of the Threat Modeling tools that are
supported by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

261
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
Threat Modeling
Critical High Medium Low Info Unspecified
Tool

IriusRisk1 Critical (76-100) High (51–75) Medium (26–50) Low (1–25) Very Low (0)
Microsoft Threat
Modeling Tool high medium low
2016
SD Elements 9+ 7–8 5–6 1–4

262
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. IriusRisk threats are assigned a severity in SRM based on their Current Risk value. The risk ratings are
mapped to SRM severities based on this mapping.

Triage Status Mapping

263
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
Threat Modeling
Ignored False Positive To Be Fixed Mitigated Fixed Reopened
Tool
IriusRisk
Microsoft Threat
Mitigation
Modeling Tool Not Applicable
Implemented
2016
SD Elements

264
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

Component Tools Mapping

The tables below show the severity and triage status mappings for all of the Component tools that are
supported by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

265
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
Component
Critical High Medium Low Info Unspecified None
Tool
Black Duck
Binary
Analysis1
*CVSSv3 >=9* >=7* , >=7** <=4* , <=4** >0* , <=0** =0* <0* , <0**
mapping
**CVSSv2
mapping

Black Duck CRITICAL, MEDIUM, UNKNOWN,

HIGH, MAJOR LOW, TRIVIAL
Hub BLOCKER MINOR UNSPECIFIED
Checkmarx
CRITICAL HIGH MEDIUM LOW INFO
One (SCA)
Dependency- medium or
critical high low informational unknown none
check moderate
Dependency-
critical high / fail warn / medium low none
Track

Dynatrace2 CRITICAL HIGH MEDIUM LOW NONE

GitHub MODERATE /
CRITICAL HIGH
Security medium
GitLab Security critical high medium low informational
JFrog Xray critical high medium low
NeuVector critical high / error medium / warn low / note
Orca Security CRITICAL HIGH MEDIUM LOW INFO

266
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Component
Critical High Medium Low Info Unspecified None
Tool
(Vulnerabilities
Scan)
Polaris critical high medium low informational
Retire.js high medium low
Snyk Open
critical high medium low
Source
Snyk License
Compliance critical high medium low informational
Management
Sonatype
critical severe moderate low no threat, none
Nexus
Veracode 4 3 2 1
low, Multiple
licenses,
high, Rejected
WhiteSource medium Multiple library License results
by policy
versions, New
library version
WhiteHat
informational,
(Legacy Rating urgent, critical high medium low
note
System)
WhiteHat
(Advanced Critical High Medium Low Note
Rating System)

267
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. To use CVSS version 3 mapping for CVSS version 2 scores, set cvss.use-cvss3-buckets = true
in the SRM props file.
2. Dynatrace only produces severities for Vulnerability results and not for Attack results. Dynatrace Attack
findings will have no severity in SRM.

Triage Status Mapping

268
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
Component Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened
Black Duck FD (feature VP (vendor
Binary Analysis disabled) patched)
Remediation
Black Duck Hub Duplicate, Ignored Mitigated
Complete
NOT_EXPLOITAB
Checkmarx One LE; URGENT;
(SCA) PROPOSED_NOT CONFIRMED
_EXPLOITABLE
Dependency-
check
Dependency- not affected,
false positive
Track suppressed
Dynatrace RESOLVED
GitHub Security CLOSED
GitLab Security
JFrog Xray
NeuVector
Orca Security
(Vulnerabilities
Scan)
dismissed (any dismissed (false
Polaris to-be-fixed
other reason) positive)
Retire.js
Snyk Open Ignored Patched

269
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Component Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened

Source
Snyk License
Compliance Ignored
Management
Sonatype Nexus Not Applicable Confirmed
Mitigate by Design,
Mitigate by
Potential False Reported to Library Network
Vericode Accept the Risk
Positive Maintainer Environment,
Mitigate by OS
Environment
WhiteSource
accepted, out of
WhiteHat Invalid, false open, mitigated
scope

270
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

Container Tools Mapping

The tables below show the severity and triage status mappings for all of the Container tools that are
supported by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

271
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
Container Tool Critical High Medium Low Info Unspecified
Anchore critical high medium low negligible
sensitive data,
Aqua CSP critical malware, high low negligible unknown
medium
Check Point
Critical High Medium Low Informational
CloudGuard
Dynatrace* CRITICAL HIGH MEDIUM LOW
Grype Reader Critical High Medium Low Unknown
GitLab Security critical high medium low informational
Harbor Critical High Medium Low Negligible Unknown
Microsoft
Defender for Critical High Medium Low
Cloud
NeuVector critical high / error medium / warn low / note
Orca Security CRITICAL HIGH MEDIUM LOW INFO
Prisma Cloud
medium /
Compute critical / important high low
moderate
(Twistlock)
Snyk Container critical high medium low
Trivy CRITICAL HIGH MEDIUM LOW UNKNOWN

272
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

*Dynatrace only produces severities for Vulnerability results and not for Attack results. Dynatrace Attack
findings will have no severity in SRM.

Triage Status Mapping

273
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
Container Tool Gone New Ignored False Positive To Be Fixed Mitigated Fixed
Anchore
Aqua CSP
Check Point
CloudGuard
Dynatrace* RESOLVED
not-fixed,
Grype Reader Fixed wont-fix
unknown
GitLab Security
Harbor
Microsoft
Defender for
Cloud
NeuVector
Orca Security
Prisma Cloud
Compute
(Twistlock)
Snyk Container ignored patched
Trivy

274
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

Cloud Infrastructure Tool Mapping

The tables below show the severity and triage status mappings for all of the Cloud Infrastructure tools that
are supported by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

275
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
Cloud
Infrastructure Critical High Medium Low Info Unspecified
Tool
Prisma Cloud
critical high medium low informational
(RedLock)
AWS Security informational,
critical, 80+ high, 60–...–79 medium, 40–...–59 low, 20–...–39
Hub* 0–...–19
Azure Security
critical high medium low informational
Center
Check Point
Critical High Medium Low Informational
CloudGuard
Microsoft
Defender for Critical High Medium Low
Cloud
Wiz CRITICAL HIGH MEDIUM LOW INFORMATIONAL

276
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

*AWS reports risk through a ranking [1–100] and a severity level [low, medium, etc.]. Both are listed.

Triage Status Mapping

277
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
Cloud
Infrastructure Ignored False Positive To Be Fixed Mitigated Fixed Reopened
Tool
Prisma Cloud
Snoozed
(RedLock)
AWS Security
suppressed notified resolved
Hub*
Azure Security
Center
Check Point
CloudGuard
Microsoft
Defender for
Cloud
Wiz

278
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

Infrastructure as Code (IaC) Tool Mapping

The tables below show the severity and triage status mappings for all of the IaC tools that are supported
by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

279
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
IaC Tool Critical High Medium Low Info Unspecified
Checkmarx One
CRITICAL HIGH MEDIUM LOW INFO
(IaC)
Checkov CRITICAL HIGH MEDIUM LOW
Orca Security CRITICAL HIGH MEDIUM LOW INFO

280
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Triage Status Mapping

281
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
IaC Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened
NOT_EXPLOITAB
Checkmarx One LE; URGENT;
(IaC) PROPOSED_NOT CONFIRMED
_EXPLOITABLE
Checkov
Orca Security

282
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

WAF Tools Mapping

The tables below show the severity and triage status mappings for all of the WAF tools that are supported
by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

283
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
WAF Tool Critical High Medium Low Info Unspecified
Imperva (WAF)

284
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Triage Status Mapping

285
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
WAF Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened None
Imperva (WAF)

286
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

STIG Tools Mapping

The tables below show the severity and triage status mappings for all of the STIG tools that are supported
by Software Risk Manager.
Tools are listed alphabetically. Tool results are mapped to the Software Risk Manager status shown at the
top of each column. (A blank cell indicates that an equivalent status value is unavailable or undefined.)

Severity Mapping

287
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 1.
STIG Tool Critical High Medium Low Info Unspecified
STIG CAT I (high) CAT II (medium) CAT III (low)

288
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Triage Status Mapping

289
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Table 2.
STIG Tool Ignored False Positive To Be Fixed Mitigated Fixed Reopened None
Not A Finding,
STIG Open Not Reviewed
Not Applicable

290
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For SRM Triage Status definitions, click here.

Tool First Seen Date

The "first seen" date reflects the earliest date that a finding was imported (or seen) by SRM, which will
either be the date the finding was first observed in SRM or the earliest date reported by a supported tool.
The following tools are supported and will provide a "first-seen" date:

• ApiSec
• Aqua
• ASoC
• AWS Security Hub
• CloudGuard
• Coverity
• Coverity on Polaris
• Dynatrace
• GitHub Security
• HackerOne
• Polaris
• Qualys WAS
• Seeker
• SonarQube
• Tenable.sc
• Twistlock
• WhiteHat
• Wiz

Correlation Overview

Correlation is the process Software Risk Manager uses to evaluate data returned by any combination of
supported AppSec tools to determine which, if any, of the results reported by the various tools refers to the
same issue. When matching results are found, Software Risk Manager correlates those results and
creates a single finding for that issue. Software Risk Manager does this by looking at the data provided for
each result; although, in some cases, the correlation process will factor in the detection method as well
(e.g., Static vs. Dynamic results).
Correlation involves various processes that check for data within results that would suggest whether
results should be correlated. The output is a per-result set of associations, where each association
indicates whether to allow or deny correlation. At the end of this process, the correlation decisions for all
results are used to determine which results have enough evidence to be grouped into the same finding.
(For more information, see Analysis Correlation Options.)
The correlation process includes the following elements:

• Rule Sets
• Data Normalization
• Location-based Correlation
• Component Correlation

291
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Hybrid Correlation
• InfraSec Correlation
• Location-less Correlation

Understanding Rule Sets

In performing cross-tool analysis, results that do not have matching data can still refer to the same issue.
In this case, correlation depends on rule sets. A rule set consists of multiple rules (e.g., specific tools and
tool codes, categories of results in a specific tool, CWEs, etc.) that are used to evaluate results and create
findings. For more information, see the section on Rule Sets.

Understanding Data Normalization

In broad terms, data normalization can be understood as the process of ordering, structuring, and
simplifying the reported data that makes up a result. The purpose is to make it easier to determine if
different data points refer to the same item. In other words, the correlation process does not evaluate the
raw data provided by a result; instead, the evaluation is based on a normalized representation of that data.
Data that is displayed on the Findings page is the normalized representation of the available data. To view
the raw data, you can open the specific finding and inspect the results attached to it.
Software Risk Manager performs the following normalizations:

• File paths*
• URL paths: Query parameters and anchors are stripped from URLs.*
• Component info: Component (package) names and versions are collected and stored as-is. CPE
strings and certain package format strings (e.g., maven, npm) are parsed to collect this information, if
available.
• Hosts: IP addresses, FQDNs, MAC addresses, NetBIOS names, and hostnames are collected when
available, and the existence of a result that ties any of these values will lead to the values being
associated as the same host. (For example, if a single result reports a vulnerability and specified
10.0.0.9 and PRODENV hostname, these two identifiers would be combined to the same normalized
host.)

* Normalization involving paths will compare the structure of the available paths to discover overlaps and
determine the correct location of a file with respect to the known structure. If a user uploads source code,
the paths from the source code are used as the normalized path. If the source code isn't uploaded, the
normalized path becomes the most specific path shared by all of the paths. For example, the paths src/
main/test.java and main/test.java would be normalized to the same, most-specific path, which is
main/test.java, because src/ is not shared between them. Base paths that are common across all
inputs may be stripped.

Understanding Location-based Correlation

Location data is essential for correlation. Results that have the same location type and value might be
candidates for correlation, depending on the location type.
Location types are as follows:

292
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• File, Logical paths: Line ranges must at least overlap. Results without a line range will only be
correlated with other results without a line range, and vice-versa. Column ranges are ignored.
• URL paths: The "Element" for both results must match exactly. An "Element" refers to the type and
name of the part of the request that was indicated as vulnerable. If a result indicates that the query
parameter "user" is vulnerable, that result will only correlate with other results with an Element of
"Query Parameter ('user')".

Understanding Component Correlation

There are five ways to correlate components (for more information, see Analysis Correlation Options).
Component correlation modes control how Software Component Analysis (SCA) tool results are correlated
to findings. SRM can be configured to correlate component results using different combinations of the
following data:

• vulnerability (e.g., BDSA-2021-0069, CVE-2021-24122)

• component name and version (e.g., Spring Framework version 3.2.4)
• type (e.g., Vulnerable Component)
• component identifier (e.g., org.springframework:spring-aop:3.2.8.RELEASE)

You will get one finding per unique set of values for each option. For example, selecting "vulnerability,
component name/version, and type" will result in a finding for each vulnerability for each component and
type that you have. However, if "vulnerability and type" is selected, you will only get a finding per
vulnerability and type that covers all components. The default mode is "vulnerability, component identifier,
and type."

Understanding Hybrid (SAST/DAST) Correlation

When Hybrid Correlation is enabled, URL-located results may be correlated with file-located results by
mapping result URLs to a set of source code locations. Results with file and URL locations may be
correlated if the file location overlaps with any of the discovered file locations for the given URL. (Data
flows are also checked for overlaps.)
Source code is analyzed (for supported languages and frameworks) to determine the specific files and line
ranges that declare the endpoint used by the URL path. If binaries are also provided, Software Risk
Manager will automatically build a call graph from the indicated source location to collect additional
locations to compare against. (Call graph generation is only supported for JVM and CLR binaries.)

Understanding InfraSec Correlation

In InfraSec correlation, results with matching Host information may be correlated if the list of CVEs is an
exact match between the available results. Results with differing host information will be marked with a "do
not correlate" flag, which will prevent correlation by any other process.

Understanding Location-less Correlation

Results that do not include location information can be correlated if the results have matching descriptors
and detection method.

293
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Findings Overview

The findings page displays all the findings associated with a particular project or projects, along with all the
relevant supporting data.
Click the Findings icon in the navigation bar to open the Findings page.

You can generate a report of the findings by clicking the Generate Report button.

Findings View Options

The Findings page provides a variety of information and project options, as detailed below. You can
customize what information is displayed by using the Configure Columns and View buttons or clicking the
column headings.

• Click Configure Columns to select which columns to display. Click to add or remove checkmarks.

294
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Click View to select which findings to display. Use the toggles to display or hide information.

The viewing options are as follows:

• Hide archived results.
• Hide findings marked as "Gone."
• Hide findings marked as "Fixed."
• Hide findings marked as "Mitigated."
• Hide findings marked as "Ignored."
• Hide findings marked as "False Positive."
The purpose of "hiding" or "un-hiding" findings is to exclude or include the associated findings from
the Findings page. The "completed" triage statuses in these options are "Gone," "Fixed," "Mitigated,"
"False Positive," and "Ignored." When turned ON, each setting will cause the findings marked with
the particular triage status to be excluded from the page. This affects the table, filters, and counts
throughout the Findings page. When turned OFF, the findings associated with that status will be
included on the page. The default setting is ON.
• Click the column heading to re-sort the list.

Findings List
The Findings page displays all the findings from the project analysis and provides analysis data as well as
links to additional information.

295
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The analysis data is displayed in columns and includes the following information:

• Severity (icon). Displays the findings severity level.

• Policy violation (icon). Indicates a policy has been violated.
• ID. The ID of the finding.
• Project (displayed when viewing a list of findings for all projects). The name of the associated project.
Click the link to open the Findings page for that specific project.
• Type. The finding type. Click the link to view details for that specific finding.
• Tool. The tool used to discover the finding.
• CWE. The finding's CWE data.
• Location. The location of the finding.
• Finding Status. The current status of the finding.
• Triage Status. The current triage status for the finding.
• Assignee. The person assigned to the finding.
• Predicted Status. Indicates the "predicted" status based on existing machine learning configuration
settings.
• Tags. Any associated tags.
• Fix By. The fix-by date.
• Attachments (icon). Shows if there are any attachments (files) attached to the finding.

Using Search/Display Filters

Filters allow you to determine which findings to display and provide information about that subset of
findings.

296
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information on filters, see Searching Using Filters.

Additional Findings Options

The process of generating and viewing finding data involves a variety of tasks. For more information, see
the following:

• Searching for Findings.

• Working with Filters.
• CWE Support.
• Performing Bulk Operations.
• Findings Table.
• Analysis Inputs List.
• Adding Manual Results.
• Using Machine Learning with Project Findings.

Searching for Specific Findings

Click the Findings icon in the navigation bar to open the Findings page.

297
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

You can search for a specific finding using the search field. Search options are located in the upper left
corner of the page.
To search using the Search field:

1. Enter a search term in the search field.

2. Open the dropdown option menu and select the type of search you want to run.
Options include the following:
• Finding Location
• Finding ID
• CVE
• CWE
• Type/Tool
• Host
• Black Duck Component Policy Violations
• Black Duck Exploit Available
• Black Duck Project
• Black Duck Solution Available
• Black Duck Workaround Available
• Brakeman Confidence
• CPE
• CVSS v2
• CVSS v2 Vector
• CVSS v3
• CVSS v3 Vector
• Checkmarx Path ID
• Coverity Merge Key
• Fortify Instance ID
• Tinfoil Api Issue ID
• Veracode App ID

298
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Veracode App Name

• Veracode Flaw ID
• Azure DevOps Work Item ID
Search results are displayed automatically.

For additional information on select search options, see the sections below.

Searching by the Finding's Location

The default "search by" option is Location, and search terms are case-sensitive. When searching by
Location, the criteria can be any part of a file path. For example, to look for Findings in the webapp/
javascript folder, enter webapp/javascript. To search Findings in files with the .java extension, enter
.java. You can use * to indicate a wildcard: a search for src/*.java will match locations like src/
main/java/Example.java. If you want to have the literal asterisk (*) as part of your search, use *. If
you want to have a literal backslash (\) as part of your search, use \.

Searching by Finding ID
When searching by Finding ID, the same formatting rules apply as with the CWE search. To search for
Finding 123, enter 123. To search for Findings 123, 456, and 789, enter 123, 456, 789. Note that the
search will not look for Findings from other projects.

Searching by CWE ID
When searching by CWE, the criteria should be a number, or a comma-separated list of numbers. For
example, to search for findings with a CWE of 91, simply enter 91. To search for findings with a CWE of
either 91 or 94, enter 91, 94. Note that ranges (e.g., 100 - 200) are currently not supported.

Searching by Type/Tool
When searching by Type / Tool, the criteria can be any text (case-insensitive) which may appear in the
name or grouping of a Rule or Tool descriptor. For example, searching for "inject" by Type / Tool can match
Rules like "SQL Injection," and Tool descriptors like PMD / Security / Possible SQL Injection. This search is
case insensitive. Wildcards are not supported.

Working with Filters

Filters allow you to target which findings you want to display, along with providing specific information
pertaining to the particular filter. For more information, see the following topics:

• Using Filters
• Configuring Filters
• Using Time Filters

299
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Using Filters to Display Findings Data

Software Risk Manager provides a variety of filters and filter options that allow you to target specific
information.
Click the Findings icon in the navigation bar to open the Findings page.

Filters are displayed to the left of the findings.

300
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Clicking the arrow icon to the left of the filter name will expand the window and show the filter options and
filter-specific information about the findings. Clicking any of the filter options will immediately apply those
parameters to the list of findings.
The available filters include the following, and are detailed in the sections that follow:

• Policy Violations
• Fix-by Urgency
• Type
• Project
• Project Metadata
• Tool
• Detection Method
• Severity
• Location
• Container Image
• Age
• First Seen by SRM
• Date Modified
• Tool Overlaps

301
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Standards
• Tags
• Assignee
• Predicted Status
• Triage Status
• Pending Triage Status
• Finding Status
• Issue Tracker Association (if configured)
• Issue Tracker Resolution (if configured)

Policy Violations Filter

The Policy Violations filter allows you to filter findings based on existing policy violations. Expand the filter
window and select which filter options you want to apply to the list of findings.

The filter window shows the number of findings and the percentage of violations compared to the total
number of findings.

Fix-by Urgency Filter

The Fix-by Urgency filter allows you to filter findings based on urgency. Expand the filter window and select
which filter options you want to apply to the list of findings.

The filter window shows the number of findings for each of the following urgency levels:

• Overdue
• Due Soon
• On Track
• No Fix-by Set

Type Filter
The Type filter allows you to filter findings based on finding type. Expand the filter window and select which
filter options you want to apply to the list of findings.

302
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The filter window shows the number of findings associated with a specific finding type.

Project Filter
The Project filter allows you to filter findings based on individual projects. Expand the filter window and
select which filter options you want to apply to the list of findings.

Note: This filter only appears on "aggregated" versions of the Findings page, that is, for "All Projects," or
for a project group with its members.

The filter window displays the projects associated with the findings in two ways:

• Projects displayed as a flat list.

• Projects displayed in a tree view.

You can switch between display modes by selecting it from the first dropdown menu in the filter's header.

Project Metadata Filter

The Project Metadata filter allows you to filter findings based on defined metadata (see Adding and
Configuring Project Metadata Fields).

Note: "Multiline" metadata is not supported.

Expand the filter window and select which metadata options you want to apply to the list of findings.

303
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: This filter only appears on "aggregated" versions of the Findings page, that is, for "All Projects."

Tool Filter
The Tool filter allows you to filter findings based on a specific tool's result types. Expand the filter window
and select which filter options you want to apply to the list of findings.

The filter window displays a list of the tools used in the analysis and the number of findings associated with
each tool. The tool result type hierarchy typically follows a hierarchy of "Tool" » "Category" » "Name,"
following the same hierarchy as in the Tool Config page.

Detection Method Filter

The Detection Method filter allows you to filter findings based on the detection method used to create the
finding. Expand the filter window and select which filter options you want to apply to the list of findings.

Note: Only the categories that apply to your project will be displayed.

The filter window lists the supported detection methods and displays the number of findings associated
with each one:

• Cloud Infrastructure Analysis: Findings pertaining to cloud-hosted infrastructure

• Component Analysis: Third-party dependencies in your project that have known vulnerabilities

304
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Container Analysis: Findings within container runtimes or container images

• Database Analysis: Findings pertaining to databases
• Dynamic Analysis: Findings detected by Dynamic Application Security Testing (DAST) techniques
• Hybrid Analysis: Findings detected by multiple detection methods, for example, Static Analysis
plus Dynamic Analysis
• Interactive Analysis: Findings detected by Interactive Application Security Testing (IAST)
techniques
• Network Analysis: Findings pertaining to network infrastructure
• Static Analysis: Findings detected by Static Application Security Testing (SAST) techniques
• Threat Modeling: Findings detected by threat modeling techniques
• Plus any custom detection method

Severity Filter
The Severity filter allows you to filter findings based on the level of severity that is reported by a specific
tool. Expand the filter window and select which filter options you want to apply to the list of findings.

The filter window displays the number of findings belonging to each of the following risk categories:

• Info
• Low
• Medium
• High
• Critical
• Unspecified

For more information on risk mapping, see Tool Status and Severity Mapping.

Location Filter
The Location filter allows you to filter findings based on the finding's location. Expand the filter window and
select which filter options you want to apply to the list of findings.

305
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The filter window shows where each finding is located, reflecting the directory and file hierarchy of the
codebase. Location categories that may apply to your project include files, URLs, and logical locations.
For .NET results, in some cases (especially if PDB files are not uploaded), source locations may not be
available. Instead, a Logical Locationsitem will be shown, along with locations organized by namespace,
class, and method.

Container Image Filter

The Container Image filter allows you to filter findings based on the names of container images that were
discovered in Container Analysis results. Expand the filter window and select which filter options you want
to apply to the list of findings.

Note: Images without an associated name are not shown in the filter.
The filter window lists the supported container images and the findings associated with each.

Age Filter
The Age filter allows you to filter findings according to when that finding first appeared in an analysis. The
Age filter calculates age based on tool-reported dates (when available). If the finding has no supported
tools, the date reported is the first time the finding was seen by SRM. Note that the "first seen" date is fluid;
that is, if new data is ingested from a tool with an earlier date, the relevant findings will be updated to
reflect this earlier date.
Expand the filter window and select which filter options you want to apply to the list of findings.

The filter window displays a set of pre-defined age ranges and the number of related findings.

306
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

First Seen by SRM Filter

The date the finding was first seen by SRM. Note: This date is not the same as the "first seen on" date for
the finding, which is shown in the header of the Finding details page.

Note: This filter will not appear on "aggregated" versions of the Findings page, that is, for "All Projects,"
or for a project group with its members.

Last Modified Filter

Displays when the finding was last modified.

Note: This filter will not appear on "aggregated" versions of the Findings page, that is, for "All Projects,"
or for a project group with its members.

Tool Overlaps Filter

The Tool Overlaps filter allows you to filter findings based on correlation logic. Expand the filter window and
select which filter options you want to apply to the list of findings.

307
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The filter windows displays a breakdown of findings based on the degree of correlation of its associated
tool results. For example, Was a finding detected by 1 tool, 2 tools, or more? Or Were the 2 tools
SpotBugs and PMD, or JSHint and PMD? Actual correlation logic is determined by the project's Analysis
Configuration.

Standards Filter
The Standards filter allows you to filter findings related to a specific industry standard. Expand the filter
window and select one or more filter options to apply to the list of findings.

The filter window displays a list of the following standards and the number of findings related to each one:

• Architectural Concepts
• CERT C Secure Coding Standards
• CERT C++ Secure Coding Standards
• CERT Java Secure Coding Standards
• CISQ Quality Measures (2016)
• CISQ Quality Measures (2020)
• CLASP
• CWE All
• CWE Development Concepts View
• CWE Research Concepts View
• CWE Top 25 Most Dangerous Software Errors (2019)
• CWE Top 25 Most Dangerous Software Errors (2022)
• DISA STIG 3.10

308
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• DISA STIG 4.10

• DISA STIG 5.1
• HIPAA
• Hardware Design
• MISRA C (2012)
• MISRA C++ (2008)
• NIST 800-53 Revision 4
• OWASP ASVS v4
• OWASP Mobile Top 10
• OWASP Top Ten (2013)
• OWASP Top Ten (2017)
• OWASP Top Ten (2019)
• OWASP Top Ten (2021)
• PCI DSS 3.1
• PCI DSS 4.0
• Seven Pernicious Kingdoms
• Software Fault Patterns
• WASC Threat Classification

Tags Filter
The Tags filter allows you to filter findings based on finding tags. Expand the filter window and select which
filter options you want to apply to the list of findings.

The filter window shows the distribution of findings based on an assigned tag. Each number corresponds
to the number of findings to which each tag has been assigned.

Assignee Filter
The Assignee filter allows you to filter findings based who was assigned to that finding. Expand the filter
window and select which filter options you want to apply to the list of findings.

309
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Predicted Status Filter (if configured)

The Predicted Status filter allows you to filter findings based on existing machine learning configuration
settings. Expand the filter window and select which filter options you want to apply to the list of findings

The Predicted Status filter is shown only if machine learning is enabled (see the Machine Learning Control
Panel section).
Filtering options include filtering against findings with Predicted Status of To Be Fixed, False Positive, or
Unknown, as well as filtering against Prediction Confidence, which ranges from 0 to 100 percent. Selecting
multiple predicted statuses to filter on will include any finding that has any one of the selected predicted
statuses. Selecting a sub range for prediction confidence will include any finding that has a predicted
status matching one of the selected statuses as well as a prediction confidence that exists in the selected
sub range (inclusively).

Note: This filter is only available in Software Risk Manager with the Machine Learning Triage Assistance
add-on.

Triage Status Filter

The Triage Status filter allows you to filter findings based on the triage status of the finding (e.g., fixed,
mitigated, etc.). Expand the filter window and select which filter options you want to apply to the list of
findings.

Pending Triage Status Filter

The Pending Triage Status filter shows triage status requests that are pending approval. Expand the filter
window and select which filter options you want to apply to the list of findings.

310
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Finding Status Filter

The Finding Status filter allows you to filter findings based on the status of the finding (e.g., new, existing,
or gone). Expand the filter window and select which filter options you want to apply to the list of findings.

Issue Tracker Association (if configured)

The Issue Tracker Association filter allows you to filter findings based on whether a finding has an
associated issue. Expand the filter window and select which filter options you want to apply to the list of
findings.

This filter option appears only if the project has been configured for issue tracking (see Issue Tracker
Configuration). The filter window shows findings broken down by whether there is an associated issue,
which issue tracker type (Jira, Azure DevOps, ServiceNow, GitLab, etc.) the issue is associated with, the
issue's status, and the specific issue.

Note: Terminology can differ between different issue trackers (e.g., "issue" vs "work item," "status" vs
"reason," etc.), but Software Risk Manager defaults to "issue" and "status" when a generic term is
needed.

311
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Issue Tracker Resolution (if configured)

The Issue Tracker Resolution filter allows you to filter findings based on resolution status. Expand the filter
window and select which filter options you want to apply to the list of findings.

This filter option appears only if the project has been configured for issue tracking (see Issue Tracker
Configuration). The filter window shows findings broken down by whether there is an associated issue,
which issue tracker type (Jira, Azure DevOps, ServiceNow, GitLab, etc.) the issue is associated with,
whether the issue is resolved, the resolution status, and the specific issue.

Configuring Filters

To make routine searches easier, you can configure and save filters that can be used by authorized users
or user groups.
Click the Findings icon in the navigation bar to open the Findings page.

312
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Filter options are located in the top left of the page.

Once a filter is selected, the list of findings will update to match the current filter state.
Configuring filters includes the following tasks:

• Creating or modifying a filter

• Viewing and setting filter permissions
• Renaming a filter
• Deleting a filter

Creating or Modifying a Filter

To create or modify a filter:

313
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

1. Click the Findings icon in the navigation bar to open the Findings page.
2. Select an existing filter from the Filters dropdown menu that you want to modify or select "All findings"
to create a completely new filter.
3. Select the filter elements that will define this filter.
When you make a change to the filter settings, an asterisk appears next to the filter name. From here
you can click the "Save" icon to update the filter with the new settings or click the "Save as" icon to
create a new filter with a new name.
Clicking the "Reset" icon returns the filter to its previously saved state.
4. Click the "Save as" icon to create a new filter.
5. Enter a new name in the filter field.
6. Click anywhere on the page to save the new name.

Viewing and Setting Filter Permissions

To view and set permissions:

1. Click the Findings icon in the navigation bar to open the Findings page.
2. Select a filter from the Filter dropdown menu.
3. Click the "Permissions" icon to open the Permissions window (shown below).
This window displays a list of users who have already been given permissions to view or edit this filter.
4. Select the Shared radio button, then click the Users or Groups button.
5. Use the "Add Users/Add User Groups" dropdown list to select the users or groups to add.
6. Click the "Add" icon.
7. Use the "Permissions" dropdown menu to set the desired permission.
8. Click Save to save your changes.

Renaming a Filter
To rename a filter:

1. Select the filter from the Filter dropdown menu.

2. Click the "Rename" icon.
3. Enter the new name in the filter field.
4. Click the "Rename" icon or click anywhere outside the filter field to save your changes.

Deleting a Filter
To delete a filter:

1. Click the Findings icon in the navigation bar to open the Findings page.
2. Select a filter from the Filter dropdown menu.
3. Click the "Delete" icon.
4. Click Delete.

314
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Using Time Filters

A Time Filter is a special type of filter which groups findings by analysis, that is, the filter will decide which
analysis each finding belongs to, and then display the groupings as a bar chart. The analysis number or
analysis date will make up the X axis, while the finding count makes up the Y axis.
Unlike the other filters, a Time Filter may not be resized vertically. Instead, as more analyses are displayed
it will grow horizontally, eventually adding a horizontal scrollbar.
Making a filter selection with a Time Filter is done by drag-selecting a range in the selection area above the
bar chart, as shown in the figure below.

The X axis of each Time Filter can be toggled between "Ordinal" and "Time."
Ordinal scale uses the analysis number (e.g. 1st, 2nd, ...) to determine where each analysis is placed on
the X axis. It allots the same amount of horizontal space for each analysis, making it a reliable way to
visually separate one analysis from another. Ordinal scale is the default mode for each Time Filter when
the page loads.
Time scale uses the start time of the analysis to determine where each analysis is placed on the X axis.
Since the lifespan of a project may be very long, and several analyses may be clustered close together,
bars may overlap when using time scale mode. This scale mode is most useful when you want to highlight
a particular date range without separating individual analyses.

As you hover over the selection area of a Time Filter, you will see a tooltip indicating the X value that your
cursor is hovering over. In time scale mode, the X value is a date and time. In ordinal scale mode, the
smaller text indicates the "physical" selection range, while the larger text indicates the rounded range,
which will be used as the actual filter selection. Once you click and drag to make a selection, the tooltip will
expand to show you the "min" and "max" of your selection.
An existing selection can be altered by clicking and dragging either of the paddles (the purple and green
paddles at either end of the selection) to resize, or the area between the paddles to pan. Double-clicking a
paddle will move it all the way to the beginning or end of the chart. Double-clicking the area between the
paddles will clear the selection.

315
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

As you hover over bars in a Time Filter's chart area, a tooltip will appear to display information about the
currently-hovered analysis. The information includes the start time, duration, number of associated findings
(the height of the bar), the analysis number (e.g. the 10th analysis in that project), and the Name.

Note that when an analysis has a name, the circle below its bar in the bar chart will be filled in; when it has
no name, the circle will only have a dotted outline. Users with the update role can edit analysis names by
clicking the pencil icon next to the name. Naming an analysis can be useful if you want to associate it with
a particular release version of your software, a Git commit, a Jenkins build, or anything similar.
In addition, analysis names allow you to write Markdown-style links, e.g., [link text](link url).

First Seen by SRM Filter

The First Seen by SRM filter is a Time Filter that groups findings based on the analysis during which the
finding was first seen in SRM; that is, the analysis that introduced the finding. This filter can be useful for
answering questions such as, "how many findings were introduced by release 2.1.0?" Note that the First
Seen by SRM filter differs from the Age Filter in that the Age filter takes into account any first-seen dates
provided by tools.

Last Modified Filter

The Last Modified filter is a Time Filter which groups findings based on the analysis during which the
finding was last modified. (For findings modified by users or other non-analysis interactions, it picks the

316
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

most recent analysis at the time of the modification.) An example usage of this filter could be in
combination with the Status Filter to answer the question "How many findings have been fixed since
release 2.1.0?" In this example, you would unhide the "completed" triage statuses by using the View
button.

CWE Support

The Common Weakness Enumeration (CWE) is a community effort lead by MITRE to provide a common
language to express software weaknesses.
Software Risk Manager leverages the CWE to provide correlation across the diverse set of testing tools it
supports. Software Risk Manager also allows you to define your own correlation logic via the Rule Set
page. This allows you to correlate based on a group of CWEs or tool specific rule codes.
Software Risk Manager uses the CWE identifier specified by the tool. In cases where the tool does not
provide a CWE, that mapping is done automatically.
CWE information is readily available in Software Risk Manager. On the Findings page, you can search by
CWE or filter by CWE. This includes grouping CWEs by various standards such as OWASP Top 10 or
CWE/SANS Top 25. The CWE identifier is also shown in the Findings Table, and you can hover on that
identifier to get the full CWE name.
CWE information is also provided on the Finding Details page. There you can see the full CWE name for
the aggregated finding. For each individual tool result, the CWE used for each tool is also provided. In both
cases, a link to MITRE's CWE website is provided.
Finally, all reports (CSV, XML, PDF, Nessus, and AlienVault/NBE) contain CWE information.

Note: Software Risk Manager currently supports CWE Version 4.14.

Performing Bulk Operations

Bulk operations are actions that affect all findings that are currently selected. When the checkbox in the top
left of the findings table is selected, these actions will apply to all findings currently displayed.
Note that bulk operations (aside from reporting) are not available on an aggregate version of the Findings
page. In addition, the checkbox selection column in the findings table will be hidden.

317
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information on bulk operations, see the following:

• Change Status. This is used to change the triage status of multiple findings.
• Change Assignment. This is used to change the user assigned to multiple findings.
• Override Severity. This is used to change the severity of multiple findings.
• Bulk Comment. This is used to add comments to multiple findings.
• Generate Report. This is used to generate a variety of report types.
• Issue Tracker Integration. This is used to interact with a configured issue tracker.
• Manage Tags. This is used to assign tags to findings or unassign tags from findings in bulk.
• Set Fix By Date. This is used to set the fix-by date of multiple findings.

Change Status

The Change Status dropdown menu is available to users with the update role. It allows users to change
the triage status of all findings currently selected.

Change Assignment

The Change Assignment dropdown menu is used to change the user assigned to the selected findings.

318
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Override Severity

The Override Severity dropdown menu is available to users with update role. It allows users to change
the severity of all findings currently selected.

Bulk Comment

The Bulk Comment button opens the Bulk Comment dialog. The dialog is used to comment on all findings
that are currently selected.

319
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Issue Tracker Integration

If a project has an Issue Tracker Configuration, the Issue Tracker dropdown menu will be available,
allowing users with the update role to interact with the configured issue tracker. Software Risk Manager
currently supports Jira, Azure DevOps, ServiceNow, and GitLab. For Jira and GitLab users, the options are
create issue, associate with existing issue, and remove association. For Azure DevOps users, the options
are create work item, associate with existing work item, and remove association. For ServiceNow users,
the options are create incident, associate with existing incident, and remove association. The examples
below assume Jira is the currently configured issue tracker.

Creating New Issues

To create a new issue for a Finding based on your current branch view, click the Jira dropdown menu and
select the Create issue... option.

A dialog will open.

All of the fields are editable. Required fields will have a red asterisk by their name.
Use the template expressions that were defined when configuring the issue tracker to pre-populate the

320
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

relevant fields with data from the active findings. Note that these pre-populated values will be based on the
current branch view where the issue is created. Software Risk Manager provides default templates for the
Summary and Description fields.
The Description field will be pre-populated with a brief description for each Finding. Jira descriptions can
be set to allow for the use of WikiMarkup. Software Risk Manager takes advantage of that to make the
descriptions more readable from within Jira.

Creating Associations with Existing Issues

For Jira users, associate a finding with an existing issue by clicking the Jira dropdown menu and selecting
the Use existing issue... option. For Azure DevOps users, associate a finding with an existing work item by
clicking the Azure DevOps dropdown menu and selecting the Use existing work item ... option. For
ServiceNow users, associate a finding with an existing incident by clicking the ServiceNow dropdown
menu and selecting the Use existing incident ... option. For GitLab users, associate a finding with an
existing issue by clicking the GitLab dropdown menu and selecting the Use existing issue... option.
Enter the issue key, work item, or incident number that you want to associate with the finding(s). Clicking
outside the textbox or pressing Enterwill cause Software Risk Manager to look up the issue, work item, or
incident in question. If SRM is able to find it, and if it's part of the same Jira, Azure DevOps, ServiceNow,
or GitLab project you selected when you configured the issue tracker for this project, or if the same
ServiceNow instance configured for this Software Risk Manager project, the issue or work item summary
will be displayed, allowing you to confirm that you've entered the issue or work item you want. Click OK to
associate the finding (or findings) with that issue or work item.

Refreshing Issue Status

Software Risk Manager will regularly check the Issue Tracker server to refresh the status for all of the
issues, work items, or incidents associated with findings in a given project. The interval at which the check
is done is configurable in the Issue tracker configuration. However, you can also manually trigger a refresh
of all the issues, work items, or incidents on the Findings page by clicking the Refresh Issues, Refresh
Work Items, or Refresh Incidents button.

Removing Associations with Existing Issues

You can remove the issue, work item, or incident associations for all of the findings in the current filter by
using the Jira, Azure DevOps, ServiceNow, or GitLab dropdown menu and selecting the Remove
association option. Note this only removes the association in Software Risk Manager; it doesn't change the
issue, work item, incident in the Issue Tracker.

Managing Tags

The Manage Tags button opens the Manage Tags dialog. The Manage Tags dialog enables users to
assign tags to findings or unassign tags from findings in bulk. The dialog is composed of three sections,
each of which will be described in sequence. Note that no operations will be applied until the OK button in
the footer of the dialog is clicked. (Clicking the Cancel will discard all dialog activity.)

321
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Current Assignments
The Current Assignments section presents a sequence of tags that have been assigned to at least one of
the selected findings. Each tag in the sequence is paired with the number of selected findings to which that
tag has been assigned (provided in parentheses next to the tag).

Bulk Assign
The Bulk Assign section allows users to select tags that should be assigned to all selected findings. The
dropdown select menu (which will appear as soon as you begin typing the name of a tag) will be populated
with tags that are available for assignment, including tags that have already been assigned to some of the
selected findings. Admins can create tags inline if they attempt to assign a tag that does not exist.

322
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The number of tags that will be attempted to be assigned once the OK button is clicked is shown in the
footer of the dialog.

Bulk Unassign
The Bulk Unassign section allows users to select tags that should be unassigned from all selected
findings. The dropdown select menu (which will appear as soon as you begin typing the name of a tag) will
be populated with tags that appear in the Current Assignments section of the dialog.

The number of tags that will be attempted to be unassigned once the OK button is clicked is shown in the
footer of the dialog.

Set Fix By Date

The Set Fix By Date button opens the Set Fix By Date dialog. The dialog is used to either set or remove
the fix-by date on all findings that are currently selected.
If a project is configured to use policies, this bulk operation is used to override the fix-by date that was
determined by the policy rules.

323
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Findings Table

The Findings Table shows a concise representation of each individual finding. The number in the ID
column is the unique identifier assigned to each finding and the text for the ID doubles as a link to the
finding's details.
Users with the update role in a project can use the dropdown menu in the Status column to change the
current status of a finding.

Projects often have more findings than can be displayed in the Findings Table all at once. Because of this,
the table is split into pages. By default, each page shows 25 findings. Users can change the number of
findings per page using the Show button, seen below.

The Findings Table columns can be hidden or displayed using the dropdown menu in the upper right
corner of the table. This is done by toggling the column name.

324
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

In the menu, visible columns have a checkmark to the left of the column name. Hidden columns can be
made visible again by selecting them in the menu.

Analysis Input List

The Analysis Inputs List is a widget on the Findings page that shows the files that were provided to
Software Risk Manager for analysis. It can be shown by clicking the Show Inputs button found in the
Findings page header.

The Analysis Inputs List is broken down first by analysis, then by file. For example, when viewing a project
in which two analyses had been performed, there would be a section for each analysis. Analyses are
ordered by date, with the most recent analysis shown at the top of the list, and the oldest analysis at the
bottom.
Within each section, individual entries represent files. For example, if a "spotbugs-results.xml" file had
been uploaded to Software Risk Manager during one analysis, a corresponding entry would appear in the
section for that analysis. Each entry has three main parts: input name, tool result summary, and archive
button.

Input Name
The first part of an entry shows the file's name and the name of the tool it came from. For auto-generated
tool outputs (i.e., files generated by any of the Software Risk Manager bundled tools), the name of the
analyzed file will be shown instead of the name of the auto-generated temporary file. Next to the names, a
download link allows users to download a copy of the file.

Tool Result Summary

The second part of an entry shows a summary of the tool results originating from that file. Note that due to

325
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

result correlation and other factors, the total tool result count will not necessarily match the total finding
count. Next to the tool result count for each entry, a bar chart shows a breakdown of the tool results by
severity. The highest-severity results are shown in red, while the lowest-severity results are shown in gray.
You can hover over each bar to see the severity it represents as well as the number of tool results
belonging to that severity.

Archive Button
Users with the create role for a project have the ability to archive an analysis input using the Archive
button located on the far right of each entry. Tool results from archived inputs will be removed. Any finding
whose last tool result was removed in this manner will have its triage status automatically changed to
Gone. Normally archival is done automatically.
When you click the Archive button for an analysis input, you will be prompted to confirm your choice.

When you confirm, the archival will be performed. The page will update to reflect the updated tool result
and finding counts.

Adding Manual Results

Software Risk Manager allows users with the create role to enter manual results to Findings data.
To add a manual result:

1. Click the Projects icon in the navigation bar to open the Projects page.

2. Locate the project and click the Project findings link to open the Project Findings page.

326
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

3. Click Add Result.

4. Enter a name for the result and select a detection method.

5. Add the required data to the "General Information" and "Contextual Information" fields.
See the sections that follow for additional information on these sections.
6. Click Add Result.

327
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

General and Contextual Information

Information entered under the Contextual Information section describes the result itself. Expanding the
General Information section of the form will allow values to be specified that will be shared among all
manual results of the same name. Contextual information will override general information if specified.
Note that this form creates results, which can be thought of as "evidence" for a finding. Multiple results
may be correlated to a single finding. As with tool results, two manual results will typically be correlated if
they have the same CWE, Location, and Detection Method, even if their names are different.

If the result name entered matches a rule in the current rule set, then the manual result will be associated
with the general information for that rule. In this case, the general information can only be changed by
revising the rule set. Both the general and contextual information will be included on the details page.

The Tool field allows the user to state that the manually-entered result actually came from a tool. The
options available to this field are configured on the admin page, in the Allowed Toolssection.

328
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Host field allows the user to describe the "host" on which the result was discovered. This normally will
only pertain to results with the Network Analysis detection method, but could also relate to Dynamic
Analysis. Host data entered on this field is considered "raw" data, (as opposed to the "normalized" data
seen on the Hosts page). Raw host data may be joined with "normalized" host data through a process
called "host normalization". By default, the "Include Host data for this result" checkbox is unchecked.
Check it to expand the host data editor.

The CVE field allows the user to enter any number of CVEs that correspond to the result. By default, no
CVEs are included. To start adding CVEs, click the Add a CVE button. When typing in a CVE text box, you
can optionally start by only typing the numbers; the text box will fill in the rest for you. If your Software Risk
Manager server is able to access the internet, it can check whether the CVEs entered by the user are real
CVEs in the CVE database. This verification comes in the form of a checkmark or an "x" on the CVE
textbox. Blank or invalid CVEs will be ignored when submitting the form.

Once you’ve completed the form, clicking the Add Result button at the bottom will dismiss the form and
update the Findings page with the new finding. A notification will appear, indicating the ID of the finding to
which the result was correlated. To delete or edit a manually added finding, click on the finding's ID in the
Findings Table to access its details view. The result will appear in the Evidence section, where there will be
buttons to edit and delete it.

Using Machine Learning with Project Findings

Note: This section is only applicable to Software Risk Manager users with the Machine Learning Triage
Assistance add-on and requires that machine learning is enabled.
Users of Software Risk Manager may review findings and change their statuses. When a finding's status
has been changed, we say that that finding has been actively triaged. The act of actively triaging a finding
is considered a past triaging decision. Software Risk Manager is capable of learning from users' past
triaging decisions in order to make predictions about findings that have yet to be actively triaged. More
details will be described in the sections that follow.

Actionability of a Finding
We use the terms Actionable and Non-Actionable to denote findings that are “real” issues and “not-real”

329
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

issues, respectively. A finding is said to be Actionable if it was actively triaged as Fixed, To Be Fixed,
Mitigated, or Assigned, if it has a status of Gone, or if it has an issue tracker association. A finding is said
to be Non-Actionable if it was actively triaged as False Positive or Ignored.

Training a Prediction Model

In order for Software Risk Manager to make predictions for findings, users will need to train a prediction
model. Training a prediction model will collect all relevant data for findings that have been actively triaged
and use that data to learn from users' past triaging decisions. See Machine Learning Control Panel for
more information about how to train a prediction model.

Predicted Status and Prediction Confidence

When Software Risk Manager is making a prediction for a finding, we mean that Software Risk Manager is
determining a Predicted Status for it. A Predicted Status for a finding is its Actionability. If Software Risk
Manager predicts that a finding is Actionable, then we say that its Predicted Status is To Be Fixed, since
Software Risk Manager thinks it's a real issue. If Software Risk Manager predicts that a finding is Non-
Actionable, then we say that its Predicted Status is False Positive, since Software Risk Manager does not
think it's a real issue. Every prediction that Software Risk Manager makes has a Prediction Confidence. A
Prediction Confidence for a Predicted Status represents how certain Software Risk Manager is of its
Predicted Status relative to the one it did not predict. Note that this is a prediction of a finding's
Actionability. That being said, Software Risk Manager's prediction may not be correct.

Requirements for Making Predictions

Software Risk Manager will only attempt to make predictions for findings if a prediction model has been
trained. See Machine Learning Control Panel for more information about how to train a prediction model.

When Will Software Risk Manager Make Predictions

Software Risk Manager will makes predictions for findings during the following situations:

• During an analysis
• After a manual result has been created
• After a prediction model has been (re)trained

In these situations, all predictions are being made automatically. During the first and third situations,
predictions are automatically made for every finding in Software Risk Manager. During the second
situation, a prediction is only made for the single manually created result. Since predictions are made
automatically, a user may note that predictions for findings might differ between reviewing sessions.

330
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Predicted Status Column

Every value in this column consists of a Predicted Status and a Prediction Confidence.

Working with Components

Software Risk Manager provides a comprehensive list of a project's components that can be accessed
through the Findings page.
Open a project's Findings page, then select the Components tab to display a list of that project's
components.

The component view shows all of the components that are part of the project, regardless of the status of
any individual finding. (Use the filters to the left of the list to search; click the column headings to sort.)
The Component page provides the following information:

• Component Name
• Version
• Match Type (direct or transitive dependency)
• License Name
• License Family

Click the component name to open the Component Details and Security Details view for that specific
component.
Select the Component Details tab to view detailed information about the component.

331
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Component Details tab provides the following information:

• Security Risk
• Component Name
• Component Description
• Component Links
• Component Origins
• Upgrade Guidance

Select the Security Details tab to view additional security information about the component.

The Security Details tab provides the following information:

• Security Risk
• Component Name
• Finding ID
• Vulnerability ID
• Vulnerability Score
• Status

332
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: If the project is configured with a component correlation mode that doesn't include vulnerability,
then the Vulnerability ID and Vulnerability Score columns won't appear in the table. (For more
information, see Analysis Configuration Options.)

Working with Findings Reports

Software Risk Manager allows you to create custom reports, create report templates, and generate reports
on a schedule. Reports provide information such the number of findings and status, triage status, and
related findings details.
For more information on reports, see the following topics:

• Generating a Findings Report

• Creating a Findings Report Template

Generating a Findings Report

Click the Findings icon in the navigation bar and click Generate Report to open the Generate Report
dialog. This dialog is used to select the type of report and allows you to customize the report.

SRM supports the following report types:

• PDF
• Compliance (PDF)

333
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• XML
• CSV
• AlienVault/NBE
• Nessus

Instructions for generating each type of report are given below, according to report type.

PDF Report
You can customize the PDF report in several ways. There are options to include or exclude a simplified or
detailed executive summary section; finding details (with or without source code); tool details; and
comments that appear in the Activity Stream (on the Finding Details page). The "Result details" section
contains these options: "Include result provided details" and "Include HTTP requests and responses."

Note: The "Include result provided details" option must be selected if you want to include the HTTP
requests and responses in the PDF report.

If you'd like your company logo to appear on the cover sheet, please contact your Software Risk Manager
administrator to configure it for you.

334
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Compliance (PDF)

XML Report
Customizations for the XML report include the option to enumerate standards violations for each finding,
provide source code snippets, and whether to include copies of the rule descriptions for each finding.
Note: There is a limit of eight lines of code per source snippet for each finding. When the limit is exceeded,
no source code is provided.

CSV Report
The CSV report provides options allowing you to select which columns will be included in the generated
file.

335
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

AlienVault/NBE Report
Software Risk Manager users will be able to select the AlienVault/NBE report. This reporter generates an
NBE report that is compatible with AlienVault.
The report options require that a host address (IPv4) be specified for inclusion in the report.

Nessus Report
Software Risk Manager users will be able to select the Nessus report. This reporter generates a report in

336
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

the Nessus format, which can be imported by many applications.

The default host and MAC address fields are required, while the operating system and NetBIOS name
fields are optional. When exporting a finding that doesn't contain any request data, the default host value
will be used.

Creating a Findings Report Template

Click the Reports icon in the navigation bar to open the Reports page. This page lists all the existing
custom report templates along with the following information:

• Name. The name of the report template.

• Owner. The owner of the report.
• Type. The type of report. Options are PDF, Compliance (PDF), XML, CSV, AlienVault/NBE, and
Nessus.
• Filter. A dropdown list of available filters from the Findings page.
• Schedule. When a report should be generated.
• Send To. Email address to send the report.
• In This Report. The number of projects associated with the report. (Click the link to view the projects.)

Clicking the dropdown configuration icon allows you to view, edit, send now (report), or delete the report
template.
To create a report template:

1. Click the Reports icon in the navigation bar.

2. Click Create Report Template.

337
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Creating a report template consists of three elements:

• Report type and definition
• Schedule
• Projects
3. Enter a name for the template and a description (optional).
4. Add a filter by clicking the checkbox (optional) and selecting a filter from the dropdown list.
Filter options will include your own saved filters, if any, along with any saved filters that are shared with
you.

Note: Saved filters that are shared with you must be copied before they can be used. A dialog will
appear asking if you want to copy the shared filter.

5. Select and define a report type. (See Generating a Findings Report for detailed instructions.)
6. Click the Schedule tab.

338
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

7. Define how often you want to run the report.

You can select a recurring day and time or day of the week and time.
8. Enter an email address where you want the report to be sent.
9. Click the Projects tab or click Next.

10. Click Add Project(s) to define which projects will be associated with this report.
11. Click Finish.

Working with Finding Details

The Findings page gives an overview of the findings in a project, focusing on a powerful filtering system,
triage workflow, and issue tracking, with links to drill into more details via the Findings Details page.
To access the details for a single finding:

1. Click the Findings icon in the navigation bar to open the Findings page.
2. Locate the finding in the Findings list and click the link in the "Type" column, which is next to the
Finding ID.

339
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For more information on each element of the individual finding page, see the following:

• Branching. Allows you to view details for different branches.

• Details Summary. Provides a quick overview of the finding and the file where it is located.
• Severity Override. Provides the option to override the finding's severity level.
• Train Now Button. Provides a link to select training modules.
• Activity Stream. Allows you to change the status of the finding.
• Description. Provides a basic description of the finding.
• Attachments. Allows attachments to be linked to the finding.
• Standard Violations. Provides a list of standard violations.
• Training Video. Provides a link to select training videos.
• Evidence. Provides the raw data (results) that make up a finding.
• HTTP Activity. Shows the available data on the HTTP request.
• AI Insight (powered by Polaris Assist).* Generate remediation guidance for a SAST issue using a large
language model (LLM). (The permission Request and view finding assessments from
Polaris Assist (Beta) for the project is required, which is included in the default Reader role
provided by SRM.)
• Source Code. Shows the contents of the file where the finding is located.
• Issue Tracker. Allows interaction with the configured issue tracker.
• Predicted Status. Provides prediction data for the finding based on the associated machine learning
configuration.
• Fix By Override. Provides the option to either override or set a finding's fix-by date.

Branching

You can select which version of a finding's details to view by changing the actively selected branch in the
dropdown. The list of branches available for selection will only include branches on which the finding
appears. All details presented for a finding will be specific to the actively selected branch.

340
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Details Summary

The Details Summary in the header gives a quick overview of the finding and the file where it is located. If
the finding is associated with a CWE, the CWE is noted, with a link to the official CWE Mitre site. The "First
seen on" date reflects the earliest date that the finding was observed, which will either be the date the
finding was first observed in SRM or the earliest date reported by a supported tool.
The summary area also has "jump links." One link will scroll the source viewer to the location of the finding
in the file. The other link (which appears once you scroll down the page) will bring you back to the top of
the page.

Severity Override

Software Risk Manager allows users (with the update role) to change the finding's severity level. The
severity override popup can be accessed by clicking the finding's severity icon from the Finding Details
page or clicking the icon next to the finding ID on the Findings page.

Once the popup is opened, select the appropriate severity level. The popup will close and the new setting
will be applied. When a finding has an overridden severity, the white border around its severity icon will
change to green.

Accessing Additional Training Modules

Software Risk Manager integrates with Secure Code Warrior by linking developers to training modules that
they can use to learn secure coding practices. If a training module is available that is related to the finding,
a link will be provided to redirect the user to the training material.

Activity Stream

The Activity Stream area has widgets that let you change the status of the finding as well as comment on
it. As users change the status and comment on a finding, messages appear in the activity stream, with

341
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

newer messages at the top. Users can only edit or delete their own comments.

Note: Actions such as triage status updates and severity overrides apply only on the currently-selected
branch. Comments are made independently of the current branch, effectively applying to all branches.
The messages shown in the Activity Stream are filtered to those relevant to the current branch.

Descriptions

The description information shown by Software Risk Manager can come from a variety of sources, with
varying levels of detail. At a high level, descriptions are divided into "general" and "contextual."

• "General" descriptions explain the type of finding, e.g. answering the question "What is SQL Injection?"
• "Contextual" descriptions explain a particular instance of the finding, e.g. answering the question "Why
is this particular code a SQL Injection risk?"

The main "Description" section of the details page is a "general" description. Most of the time, the main
description comes from a Rule Set. When a finding matches up to a rule, the main description section will
use that rule's description. For findings created by observed tool results (i.e. types of findings that Software
Risk Manager doesn't already know about - see the Tool Configurationsection), if the tool result does not
match a rule, the general description may be created from that tool result, as long as the tool result
provides one. This will often be the case with tools such as Fortify and Veracode.

342
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The finding itself will not have a "contextual" description. This will instead be found on the individual results
shown in the Evidence section. The "general" and "contextual" descriptions for results will be shown in the
Tool Rule Description and Contextual Description sections of their display area, respectively (see below).

Training Video

Software Risk Manager integrates with Secure Code Warrior by providing training videos that developers
can use to learn secure coding practices. Software Risk Manager will present these videos on the Details
page when they are available.

343
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: The training videos use the video/mp4 MIME type, which may not be supported by some
browsers.

Standard Violations

The Standard Violations window lists which standards were violated in this finding.

Evidence

The Evidence section of the Finding Details page shows the raw results that make up a

344
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

finding—regardless of whether the finding originated from an analysis tool or a manual entry. Each result in
the Evidence section will be displayed in its own subsection, with the result's "type" as the header.

Each result in the evidence section includes the following fields:

• Detection Method. Describes how the result was discovered (e.g., what type of analysis was
performed), typically either "Static Analysis" or "Dynamic Analysis."
• First Seen On. For supported tools, reflects the date that the result was observed by that tool.
• Location. Describes exactly where the result was reported, i.e. a file, line number, and column number,
or a URL. Note that because Software Risk Manager attempts to normalize locations, a result's location
may differ slightly from the location of the finding it belongs to.
• Tool. The name of the tool that reported the result.
• Tool Code. The raw "code" that describes the type of the result (for example, "SQL Injection").
• Tool Category. The raw "category" (depending on the tool, the terminology may differ, e.g., "group") to
which the tool code belongs.
• CWE. The Common Weakness Enumeration item reported by the tool, if available. Note that because
Software Risk Manager uses Rule Sets to determine how results are combined into findings, a result's
CWE may differ from its finding's CWE. To control this behavior, create or choose a different Rule Set to
use in your project's Analysis Configuration.
• CVE. The Common Vulnerabilities and Exposures identifier reported by the tool, if available.
• Severity. The Software Risk Manager equivalent of the tool's reported severity. Note that some tools
use different terminology for this, such as "priority," or different scales, like "1 through 10." Also note
that when multiple results of different severities are combined, the finding will either take the severity of
the rule that joined them or the highest severity from among the combined results.
• Related Findings. Lists any other findings that share the result, when applicable. This is more common
when dealing with DAST and Hybrid results, as correlation between DAST results is less strict than with
SAST.
• Tool Rule Description. The tool's unique description of the type of result being reported. For example,
with a SQL Injection result, this is where you could find the tools' description of what SQL Injection is.

345
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Click the "show more" and "show less" links to expand and collapse the description.
• Contextual Description. The tool's description of the specific result. For example, with a SQL Injection
result, this is where you could find out how this particular part of your codebase is vulnerable to SQL
Injection. Click the "show more" and "show less" links to expand and collapse the description.
• Host Info. Shows the raw host data of the result being reported for Network Analysis results as well as
certain DAST results. The host data is displayed as a table, with the left column indicating the host
"field" (e.g., Fully Qualified Domain Name (FQDN), Hostname, IP Address, etc.), and the right column
containing the values for that field. The Also include values from host normalization checkbox will cause
the page to include any values from the "normalized" version of this host to also be displayed. The
"normalized" host is what is shown on the Hosts page. Values present on the normalized host and not
present on the raw host will be rendered in green.
• HTTP Activity. This is shown for DAST results, and it will expand to its own subsection, which is
described here.

Some tools report additional information that may appear in this section, such as Veracode's Flaw ID.
When these additional fields are present in a project, some of them may become available as a finding
search option on the Findings page.

HTTP Activity

The Http Activity section shows any detail Software Risk Manager knows about the HTTP request and
response associated with a DAST result.

346
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The table at the top of the HTTP Activity section enumerates the "variants" of request/response that were
reported with the result. Some tools will attack the same URL with different variations of query parameters
and form parameters to try and find vulnerabilities, then report each variant as part of the same result.
Other tools will report each variation as its own result, but if Software Risk Manager sees that everything
else is the same, it may join them together under a single result. Often times, there is only one variant
reported, as is the case in the screenshot above. In cases where there are multiple variants, click on the
different rows of the variants table to show the details for that variant in the sections below.
For each variant, the details are described in the sections that follow.

Request Tab
The details of the HTTP request are broken down here:

• Query Params will show any applicable query parameters (i.e. parts of the URL after the ?, e.g.
?foo=1&bar=2)
• Request Headers shows each of the headers sent with the HTTP request, as a table.
• Request Body shows the body data sent with the request, if applicable. This is where form parameters
go, or any other arbitrary content being sent to the server.
• Raw Request Data shows the raw, un-parsed version of the request. Note that some tools don't report

347
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

this, instead reporting specific details of the request. In these cases, the raw request will be
reconstructed automatically.

Response Tab
The details of the HTTP response are broken down here:

• Response Headers shows each of the headers sent with the HTTP response, as a table.
• Response Body shows the body data sent with the response, if applicable. Expanding it will show a
text view of the raw response data. Note that response bodies are typically rather large, and are
sometimes non-text data, which may make this view difficult to use. Software Risk Manager will not
attempt to render whatever the data represents, since the assumption is that the response contained
some vulnerability like cross-site scripting, or a malicious file.

Metadata Tab
Some tools will report extra "metadata" with their HTTP activity. When applicable, this data will be shown in
the Metadata Tab as a table.

AI Insight Using Polaris Assist

When Polaris Assist is configured and enabled, an "AI Insight" section will be available for findings which
have a Static Analysis detection method and have the required information for at least one of the available
assessments listed below. (For information on configuration, see Polaris Assist.)

Note: Users must have the permission Request and view finding assessments from
Polaris Assist (Beta) for the project, which is included in the default Reader role provided by
SRM.

Warning: Polaris Assist generates results created by artificial intelligence (AI) or other automated
technologies. Such results are provided for informational purposes only and should not be relied upon for
any specific purpose without verification of its accuracy or completeness.
Click the AI Assist button to expand the fields.

348
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

When possible, SRM will offer up to three sub-assessments:

• Summary. Polaris Assist will provide a brief summary of the vulnerability and its impact. Requires
finding description and CWE.
• Code Analysis. Polaris Assist will summarize an excerpt of the affected code and surrounding lines
and a description of the vulnerability in the context of the affected code.
• Code summary requires a file location with source code.
• Vulnerability analysis requires a file location with source code, finding description, and CWE.
• Fix Suggestion. Polaris Assist will suggest an updated code snippet that attempts to address the
vulnerability.
• Requires a file location with source code, finding description, and CWE.

Source Code

The Source Code area shows the contents of the file where the finding is located. The "line" link will scroll
the source display so that it shows the exact lines of the finding, which are highlighted in dark grey in the
line number gutter. The presence of severity markers in the gutter denote other findings in the same file.
When multiple findings are present in a single line, the severity marker will show the highest-level severity
at that line. If you hover your mouse over any highlighted lines, a popup containing links to the Finding
Details pages for the other findings will appear.

349
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Source Search
Searching within the Source Code area is separate from your browser's default search function. (For
performance reasons, the Source Code view does not render the entire source file at once, so your
browser might not be able to find lines that are not currently in view.) Click in the Source View first.

Issue Tracker

If a project has an Issue Tracker Configuration, the Create issue and Use existing issue buttons will be
shown for Jira and GitLab users, Create work item and Use existing work item for Azure DevOps users,
and Create incident and Use existing incident for ServiceNow users. Users with the update role are
allowed to interact with the configured issue tracker.

Creating an Issue
You can click the Create issue, Create work item, or Create incident button, which will open a dialog.

350
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The dialog functions the same way as the dialog opened from the Bulk Operations area of the Findings
Table, except the Description field will be pre-populated with information about this finding. When manually
creating an issue in this way, the issue will be associated with the current branch view and will reference
that finding's branch-specific data (e.g., Severity and Status).

Note: In contrast to manual issue creation, Auto Create currently only supports associating issues with a
project's default branch.

Associating a Finding with an Existing Issue

Click the Use existing Issue, Use existing work item, or Use exiting incident button to associate this finding
with an existing issue, work item, or incident. A dialog will open.

Refreshing Issue Status

Select the refresh icon to manually trigger a refresh of the issue or work item.

351
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Removing Associations
Clicking the trash icon removes the association between the finding and its related issue or work item.
Note: This only removes the association; it doesn't touch the issue or work item itself.

Predicted Status

Note: This section is only applicable to Software Risk Manager users with the Machine Learning Triage
Assistance add-on.
A finding’s prediction is included on the Finding Details page only if machine learning is enabled on the
Machine Learning Control Panel. Each prediction is presented as a Predicted Statusand a Prediction
Confidence. Users can set a finding’s Status to its Predicted Status by clicking on the Use Prediction
button, which is next to the finding’s prediction.

Fix By

Software Risk Manager allows users (with the update role) to change the finding's fix-by date. If the
project is configured to use policies, a user can override a fix-by date that was determined by a policy rule.
If the project is not configured to use policies, a user can simply set or remove a fix-by date.
The controls for setting the fix-by date are located under the finding severity information, above the tag
controls.

The dropdown allows the user to either pick a specific date to set as the finding's fix-by date, or the user
can choose to remove a finding's fix-by date.

Attachments

352
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Allows files to be attached to the finding. Existing attachments are listed here.

To attach a file, click the Add Attachment button and select a file or use drag-and-drop. Click an
attachment to download its contents. To delete an attachment, click the dropdown configuration icon and
select Delete.

Triage Status Definitions

SRM Triage Status definitions are as follows:

• Not Triaged. (Not yet assigned a status.) The finding has not been assessed or categorized.
• Fixed. The finding has been directly fixed in the current version of the software and is awaiting
confirmation by a later scan which would set the Finding Status to "Gone."
• Mitigated. The vulnerability has not been fixed, but steps have been taken to reduce its impact or
likelihood.
• Ignored. The vulnerability has been deemed insignificant and does not currently warrant action.
• False Positive. The reported finding is not an actual vulnerability. After review, it is determined to be
incorrect or misleading, and no action is needed.
• To Be Fixed. The finding has been assessed and flagged as important and therefore needs to be fixed.
• Reopened. The finding has been reopened per the analysis configuration settings. (See Analysis
Configuration Options.)

Finding Status Definitions

SRM Finding Status definitions are as follows:

• New. The finding was new in the last analysis that detected it.
• Existing. This finding has been detected in more than one analysis.
• Gone. This finding is no longer being reported by any tools.

Project Dashboard

The Project Dashboard provides a comprehensive overview of a project, displaying a set of analytic and
trend data which are automatically updated as you use Software Risk Manager.

353
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

You can open the dashboard from the project list page or the project findings page:

• From the findings page, click the Project Dashboard tab at the top of the page.
• From the project list page, open the task dropdown list and select "Dashboard."

When viewing the Project Dashboard for the parent of grouped projects, you will have the option to include
data from the child projects by using the roll-up feature. To do this, enable the Include child projects switch
on the top right corner of the Project Dashboard page.
You can also access the Project Dashboard for "all projects" by clicking the "Dashboard" tab while on the
aggregate "All Projects" Findings page.
While on the Project Dashboard page for a project with multiple branches, you can switch the view to a
different branch by clicking the branch selector dropdown in the page header.

Dashboard Data
The Project Dashboard is divided into several sections:

• Risk Score. Provides a "letter grade" to indicate the overall quality of the project.
• Open Findings. Displays the total number of findings, along with a breakdown of the number of findings
in each category and the percentage of findings that have been triaged.
• Findings Count Trend. Shows the number of findings over time, broken out by detection method.
• Average Days to Resolution. Shows the average number of days it took to resolve an issue, broken out
by severity.

354
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• Code Metrics. Displays various metrics for the project's codebase, such as the number of lines of code,
number of source files, etc., broken down by language.
• Analysis Frequency. Provides detailed information about when the analysis was run, how long it took,
tools used, etc.
• Activity Monitor. Displays a "calendar heatmap," representing the analysis activity on the project over
the past year.
• Created vs. Resolved. Provides a visual representation of the dueling trend of new findings that are
added to the project and findings that are resolved by the team, along the difference between the two.
• Top Finding Types. Shows the top 10 types of findings in the project, by number of open findings.

Risk Score
The Software Risk Manager Risk Score section of the Project Dashboard provides a letter grade to
indicate the overall "quality" of the project.
Figure 1. Risk Score

The letter grade is based on a percentage score, which is the average of the Custom Code Score,
Component Score, and Infrastructure Score. Each score is weighted evenly, but note that an Infrastructure
Score is not available for all projects. The score letter grades are = A, [80, 90) = B, [70, 80) = C, [60, 70) =
D, [0, 60) = F.

• Custom Code Score starts at 100% and is reduced based on the "volume" and "variety" of non-
"Component" and non-"Infrastructure" findings.
• volume penalty =(3.0% × log2(num_critical_findings + 1)) +(1.5% ×

355
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

log2(num_high_severity_findings + 1)) +(0.75% × log2(num_medium_severity_findings + 1)).

• variety penalty =(3.0% × num_critical_finding_types) +(1.5% × num_high_severity_finding_types)
+(0.75% × num_medium_severity_finding_types).
• Component Score starts at 100% and is reduced based on the "volume" of "Component" findings.
"Component" findings are any findings found when running Component tools.
• volume penalty =(3.0% × num_critical_component_findings) +(1.5% ×
num_high_severity_component_findings) +(0.75% × num_medium_severity_component_findings).
• Infrastructure Score (only reported for projects that have findings from infrastructure analysis) starts at
100% and is reduced based on the "volume" of infrastructure findings. Infrastructure findings are any
findings found when running Infrastructure or Cloud Infrastructure Tools.
• volume penalty =(3.0% × num_critical_infrastructure_findings) +(1.5% ×
num_high_severity_infrastructure_findings) +(0.75% ×
num_medium_severity_infrastructure_findings).

Each of the "num_" values mentioned above refer to findings in the project which haven't been triaged (i.e.,
findings whose triage statuses haven't been marked as one of the "resolved" statuses like "Fixed" or "False
Positive"). In the case of "volume," they refer to the number of findings. In the case of "variety," they refer
to the number of distinct types of findings. Only critical, high, and medium severity findings are counted
against the Software Risk Manager Risk Score.
Next to the letter grade, the specific percentage score is displayed alongside a spark-line that shows the
general trend of the project's Software Risk Manager Risk Score over the past week.
The individual scores for the Custom Code Score and Component Score are shown by a pair of "fill bars"
next to the letter grade, below the overall score percentage.
For more information on how these scores are calculated and how to customize the formula, see the
Software Risk Manager Scoring Calculations section in the Software Risk Manager Install Guide.

Open Findings
The Open Findings section shows the overall "triage status" of the project.
Figure 2. Open Findings

356
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

A waffle chart is used as a severity-age breakdown of the untriaged findings in the project. Different colors
indicate different severities, as indicated by the legend. The number of dots of each color indicate the
percentage (rounded) of findings in the project which have that specific severity. I.e. if there are 19 purple
dots, it means 19% of the untriaged findings have "critical" severity. Transparency is used to indicate the
relative age of the findings, as indicated by the legend. A lighter (more transparent) version of the severity
color indicates findings of that severity which are relatively new. A darker (more opaque) version of the
severity color indicates findings of that severity which are relatively old.
Clicking on the severity labels in the waffle chart's legend will cause the chart to focus on that severity,
fading the other severities from view. Clicking again on the same label will reset that focus, returning the
visualization to its normal state.
Hovering the mouse cursor over the severity labels in the waffle chart's legend, or over the colored dots in
the waffle chart itself will cause the chart to temporarily focus on that severity. This effect is similar to the
click effect described in the previous paragraph, but the effect does not persist if the mouse leaves the
area that caused the focus. Hovering the mouse over the chart will also show a tooltip containing a
summary of the respective hovered severity.
Below the waffle chart is a fill-bar indicating the percentage of findings which have been triaged (i.e. set to
Fixed, Mitigated, False Positive), out of the total number of findings in the project, excluding findings that
are marked "Gone".

Findings Count Trend

Figure 3. Findings Count Trend

357
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Findings Count Trend section of the Project Dashboard shows a breakdown of findings by "detection
method" over time.

358
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The Findings Count Trend visualization uses a stacked area chart, with "date" as the X axis, and total
finding count as the Y axis. By default, an area for each detection method is shown, so that the stacked
areas' total height indicates the total number of findings at a given date. Clicking one of the detection
method labels in the legend will cause the visualization to focus on the respective detection method, hiding
the other areas and moving the focused area to the bottom of the visualization. Clicking again on the same
detection method label in the legend will remove the focus effect, returning the visualization back to its
default state.
Hovering the mouse cursor over the visualization will cause a vertical line to snap to the nearest date,
updating the legend to reflect the finding counts at that date. While the mouse cursor is not over the
visualization, the vertical line will snap to the latest date, causing the legend to reflect the most recent
finding counts

On the top-right of the trend graph is a calendar icon, which can be clicked to bring up a menu for selecting
a date range.

359
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Selecting one of these range values will automatically refresh the graph to the selected range. For larger
date ranges, each point in the graph can represent multiple dates by taking the average of data samples
involved.

Average Days to Resolution

The Average Days to Resolution section of the Project Dashboard shows the average number of days it
takes for a new finding in the project to be resolved.
In this context, resolution means the finding either becomes "Gone" (because developers fixed the issue,
and a new analysis did not encounter the same finding), or its triage status was set to one of the "resolved"
statuses: False Positive, Fixed, Ignored, or Mitigated.

For each severity, the average number of days it takes to resolve a finding of that severity is displayed in a
badge. Initially, each badge will display "N/A"; since no findings have been resolved, there is no "average"

360
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

time. A colored bar below the badges acts as a legend, and hovering the mouse cursor over a badge
causes it to become highlighted with that severity's respective color.
As a rule of thumb, teams may wish to prioritize addressing higher-severity findings, so team leads will
want to see a lower number of days-to-resolution for higher-severity findings.

Code Metrics
Figure 4. Code Metrics

The Code Metrics section of the Project Dashboard displays a set of metrics for the project's codebase,
broken down by language.

On the left of the section, a legend shows:

361
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• An "Overall" group which represents the entire codebase; the sum of the metrics for each language.
• The top 5 languages (by percentage of lines of code in the respective language compared to the total
number of lines of code).
• An "Other" group which contains the summation of any other languages after the top 5.

The colors assigned to each language are purely aesthetic, and are chosen using the same color scheme
that Github uses.
By default, the "Overall" group is selected, so the metric areas to the right will show stats for the whole
codebase. Clicking one of the languages, or the "Other" group in the legend will cause the metric areas to
display language-specific stats. Clicking on the "Overall" group will return the display to its default state.

When focused on a particular language, each metric will show an "X / Y" value instead of the usual "Y".
The "Y" indicates the metric's value for the entire codebase, and the "X" indicates the metric's value for the
subset of the codebase which is written in the focused language.
Each metric area will also show a sparkline indicating that metric's trend over the past week. The
sparklines will be colored blue for "good" changes, and red for "bad" changes.

List of Code Metrics

• Lines of Code shows the number of lines of code (including blanks and comments) in the project's
codebase. A rising number of lines of code is considered "good", as it implies the project is growing.
• Comment-to-Code shows the ratio of the number of comment lines to the number of total lines of code
in the project's codebase. A rising comment-to-code ratio is considered "good", as writing comments is
good development practice.
• Source Files shows the number of source files in the project's codebase. A rising number of source
files is considered "good", as it implies the project is growing.
• Cyclomatic Complexity shows the average cyclomatic complexity number (CCN) of the project's
codebase. A falling CCN is considered good, as less-complex code is easier to maintain.
• Code Churn shows the number of changed lines of code. Since all dashboard data is collected nightly,
the value displayed today indicates the amount of code churn that occurred yesterday. A rising code
churn is considered "bad", as high churn tends to increase the chance of introducing new
vulnerabilities.
• Finding Density shows the number of findings per thousand lines of code in the project's codebase. A
falling finding density is considered "good" since it means the defective percentage of the codebase is
shrinking.

362
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Analysis Frequency
The Analysis Frequency section of the Project Dashboard offers a summary of the project's most recent
analyses.
Figure 5. Analysis Frequency

At the top of the section, a text blurb describes when the latest analysis occurred, and how long it took.
The rest of the section is broken down into three tabbed sections.

Analyses
This shows how many analyses were run on the project over the past week, 4 weeks, and 3 months.

363
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Tools
This shows how many unique tools were run in analyses on the project, over the same time periods. (Note
that in this context, "tools that were run" means the set of Tools referenced by Findings in Software Risk
Manager. It doesn't matter whether you ran the tool separately, or if Software Risk Manager orchestrated a
run of the tool on its own.)

Activity Monitor
The Activity Monitor section of the Project Dashboard shows a "calendar heatmap" which represents the
analysis activity on the project over the past year.
Figure 6. Activity Monitor

364
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

The far left represents dates from a year ago, and the far right represents recent dates. Stepping down a
column of the chart, each bubble represents a day of the week, with Sunday at the top, and Saturday at
the bottom. Hovering the mouse cursor over any of the bubbles in the chart will cause a tooltip to display
the bubble's respective date, and the number of analyses that were run that day.

The analysis activity is broken down by different types of analyses, e.g. Static and Dynamic. The legend
items below the visualization represent these different analysis types (i.e. "Detection Methods"). Note that
any given analysis may result in findings of different detection methods, depending on what files were

365
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

uploaded. Clicking the legend items below the visualization will cause the visualization to focus on the
legend item's respective detection method. This can cause the number of analyses shown in the tooltip to
change. For example, three analyses may have been run on a given day, but only two of those analyses
resulted in data from Dynamic Analysis. In this case, if the "Overall" legend item was selected, the tooltip
would show "3 analyses on {date}", but when the "Dynamic Analysis" legend item was selected, the tooltip
for that same bubble would show "2 analyses on {date}."

The visualization uses brightness to indicate more or less analysis activity for each given day, as indicated
by the legend above the visualization. A darker shade of color indicates more analyses, and a lighter/
whiter shade of color indicates fewer analyses.

Created vs. Resolved

The Created vs. Resolved section of the Project Dashboard shows the dueling trend of new findings that
are added to the project, findings that are resolved by the team, and the difference between the two.

366
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

This section is broken into two pieces; the graph, and the table. Both represent the same data.
The graph is broken into two pieces; the "duel", and the "trend".
The "duel" section shows the number of created findings (in red) versus the number of resolved findings (in
green). By default, the graph will show an accumulation of these numbers, starting from date at the far left
of the graph. The icon in the upper-right corner of the Created vs. Resolved section opens a menu which
allows you to toggle between "accumulated" and "daily" counts in the "duel" section. "Daily" counts show
the exact number of created and resolved findings for any given day. The colored area between the lines in
the "duel" section of the graph indicates which line is higher. A green fill means more findings were
resolved as of that day (if using "accumulated" counts), or resolved on that day (if using "daily" counts).
The "trend" section of the graph shows the difference between the red and green lines of the "duel" (in
blue). The "duel" and the "trend" graphs have their own separate Y axes representing cumulative finding
counts, and count difference, respectively. The two graphs share the same X axis, which represents the
date.
When hovering over the graph with the mouse cursor, a vertical line will snap to the nearest date to the
mouse, causing the legend above the graph to update its numbers to reflect that date. The corresponding
row in the table to the right of the visualization will be highlighted, and the table will auto-scroll to that row if
necessary. Similarly, hovering over the table will cause the same changes, depending on which row in the
table is hovered.
By default, the Created vs. Resolved section shows the accumulated number of findings since the
beginning of the summary time window. Click the graph icon in the upper-right corner of the section, and
select "Show daily counts" to switch the graph to Daily mode. Daily mode shows the change in values on a
day-to-day basis. Accumulated mode can be considered the Integral of Daily mode, and Daily mode can
be considered the Derivative of Accumulated mode.

367
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

On the top-right of the graph is a calendar icon, which can be clicked to bring up a menu for selecting a
date range.

Selecting one of these range values will automatically refresh the graph to the selected range.
For larger date ranges, each point in the graph can represent multiple dates by taking the sum of data
samples involved.

368
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Top Findings Types

The Top Finding Types section of the Project Dashboard shows the top 10 types of findings in the project,
by number of open findings.

The visualization uses a Stream Graph to represent the relative volume of the top finding types (Y axis)
over time (X axis). Each stacked area of a given color represents a specific type of finding, e.g. "SQL
Injection". The height of each area represents the number of findings of that type on a given day.
The table to the left of the visualization acts as a legend, where each of the finding types is labelled, and
has a colored fill-bar indicating the respective finding type's percentage share of the project.
Hovering the mouse cursor over an item in the table to the left of the visualization will highlight the
corresponding area in the visualization. Similarly, hovering the mouse cursor over an area in the
visualization will highlight the corresponding item in the table. Clicking an item will cause that item to
become "focused". Click the item again to undo the focused state, or click another item to change to
another focused state.

369
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

As with many of the other dashboard sections, hovering the mouse cursor over the visualization will cause
a vertical line to snap to the date nearest to the mouse. When this happens, the table to the left of the
visualization will update to reflect the percentages for that day.
Click the graph menu in the upper-right corner to access the "layout" options. By default, the graph uses
"stream" layout. Switch to the "stack" layout to rearrange the items into a stack, such that the bottom of the
stack aligns with the "0" on the Y axis. Note that with the "stream" layout, the Y axis's meaning differs from
date to date, so no axis numbers will be displayed.

On the top-right of the graph is a calendar icon, which can be clicked to being up a menu for selecting a
date range.

Selecting one of these range values will automatically refresh the graph to the selected range.
For larger date ranges, each point in the graph can represent multiple dates by taking the average finding
counts of data samples involved.

370
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Hybrid Correlation

Hybrid Correlation, at its core, enables results from DAST tools to be correlated with results from SAST
tools. This gives better visibility into how findings may actually be exploited in the wild as well as help
identify test cases for those findings. Software Risk Manager currently has support for one form of Hybrid
Correlation, which can infer possible execution patterns.
For more information, see the following section:

• Agentless Correlation

Agentless Correlation

Agentless correlation uses a static analysis approach on source code and binaries to correlate SAST and
DAST results. No configuration steps are required to make use of agentless correlation. The only
requirement is uploading source code at some point in an analysis.

Correlation Performance Impact

Agentless Correlation greatly expands the set of possibilities that must be considered to create a hybrid
finding. Since exact code paths aren't provided, many inferred paths are created and evaluated during
correlation. This can greatly impact the speed of correlation during analysis.

371
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Requirements and Known Limitations

For information on requirements and known limitations, see the following topics:

• Requirements.
• Known Limitations.

Agentless Correlation Requirements

If Hybrid Correlation is enabled, Agentless Correlation is automatically applied for any project with
correlation enabled and with uploaded source code.

Source Code
Agentless Correlation relies on the availability of source code to detect endpoints and their locations within
a codebase. From this alone, DAST and SAST results that occur at an endpoint handling function can be
correlated.
Only source code declaring and implementing endpoints are required. Source code for dependencies and
utility libraries are not necessary, unless they declare and implement endpoints.
Endpoint detection is supported for a specific set of languages and web frameworks. These are as follows:

• Java: JSPs, Servlets, Struts, Spring MVC

• C#: ASP.NET MVC, Web Forms
• Ruby: Rails
• Python: Django

Effectiveness of endpoint detection can vary depending on the use of plugins and unconventional endpoint
routing methods within the source code.

Binaries
Binaries for your application can also be uploaded to improve Agentless Correlation. If binaries are
available, a call graph can be generated and explored to find code paths to SASTs from a detected
endpoint. All relevant binaries for your application—the compiled application and its dependencies—should
be uploaded with debug symbols for the best results.
Hybrid Correlation through call graph analysis is supported for binaries on the following runtime
environments:

• JVM (Java, etc.)

• CLR (C#, etc.)

Agentless Correlation Known Limitations

372
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Agentless Correlation explores a set of possible execution paths from an endpoint to find correlations with
a code location. These explored paths may be inactive or incomplete due to undetected endpoints,
inheritance and strategy patterns, anonymous functions, or other features for a given language and web
framework.

Rule Sets

The Rule Set Page is accessed via the Rule Set Associations section of a project's Analysis Configuration
dialog. When you access the Rule Set page, you will be able to view and sometimes edit a set of rules that
can be used to determine how different types of findings will correlate with each other.
Each Rule Set has Rules, and each Rule has Criteria and identifying information.
Rule Sets are, as the name implies, a set of rules. Each rule acts as a strategy for combining results from
different tools and providing standard information for the finding. Within a rule, a set of criteria can be
defined, forming the underlying logic for the rule. The identifying information for a rule can optionally
include a Severity, CWE, and Description, which will be shared by Findings created from that rule. For
example, a general "SQL Injection" rule may be created to capture specific results from multiple tools and
provide a shared description, making it easier to locate and recognize standard vulnerabilities.
When result data is uploaded to a Software Risk Manager project, as long as that project's Prevent
Correlation setting is not enabled, its associated rule set will be responsible for determining which types of
results represent the same types of problems. In this case, rules will be applied during ingestion, when
findings are created from tool results. If there are multiple tool results belonging to the same rule and they
occur at the same location, they will all be associated with the same finding. Whether a tool result
"belongs" to a rule is determined by that rule's criteria.

After Changing Rule Sets

Since a project's configured rule set determines the manner in which results are correlated, changing that
configuration necessitates an update of the correlation. This happens when the configured rule set for a
project is modified in any way, or the Analysis Configuration is changed to use a different rule set. When
this happens, the Findings page will display a notification prompting users to do so.

Additional Information
For more information on identifying information and rule criteria, see the following topics:

• Rule Identifying Information.

• Rule Criteria.

Rule Identifying Information

The identifying information for a rule includes severity, CWE, and a description. These fields are all
optional. When provided, they will alter the corresponding values for findings associated with that rule.
Each rule's identifying information is collapsed by default. To expand it, click the dropdown configuration
icon and select View Details.

373
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

If you have the admin role, you can edit an existing rule's identifying information (aside from the read-only
Software Risk Manager rule set).
To rename a rule, click on its name to open an edit window. Enter a new name then press Enter.

To change the severity, CWE, or description for a rule, expand the identifying information section, then click
the pencil icon next to the corresponding header. This will activate an inline form allowing you to make
changes to the value. Once you've set the desired value, click Save to apply the change. Click Cancel o
discard your changes without saving.

You can add criteria from editable rules via the forms at the bottom of each rule's criteria list.

Rule Criteria

A rule's criteria control which tool results will be matched with a rule. Note that each criterion can only
appear once in a rule set. If you attempt to add a criterion that already exists in a different rule, you will be
given the option to move the criterion out of that rule, or cancel. Users with the admin role can edit the
criteria for each rule.
Criteria can be created for rules using the add criterion buttons for that rule. These buttons are located at
the bottom of the criteria list.

374
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Criteria can be deleted from rules using the delete button for that criterion. The button is hidden until you
hover over the criterion in a rule's criteria list.

Tool Criteria
The Add Tool Criterion form allows you to create criteria that operate on a tool result's type. An individual
tool criterion specifies a tool, category, and code. It will match tool results whose raw values match the
values specified by the criterion.

The exact values for the tool criterion fields vary depending on what is reported by the tool. One way to
discover these values is to look at the Finding Details page for existing findings in Software Risk Manager.
The Tool, Tool Category, and Tool Code are displayed in the Tool Details for each associated tool result.

The category and code fields are both optional. Omitting both will create a criterion that matches all results
from the specified tool. Omitting just the code will create a criterion that matches all results from the
specified tool marked as part of the specified category. Some tools do not specify a tool category, in these

375
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

cases the tool category field will need to be left blank.

Note: Leaving the tool category field blank does not act as a wildcard, so if the tool specifies categories,
they must be included in all rule criteria.

CWE Criteria
The Add CWE Criterion form allows you to create criteria that operate on a tool result's CWE. By
specifying a CWE ID value, a CWE criterion will match tool results with that CWE value.

Hosts

Note: this section is only applicable to Software Risk Manager users with the InfraSec add-on.
When Software Risk Manager ingests Network Security results, the location of those results is typically
expressed in terms of a "host," with the level of detail varying from tool to tool. The Hosts page is Software
Risk Manager's location for interacting with host data directly, outside the context of Findings or Projects.
Users will be able to access the Hosts page but the Associated Projects column will only populate for
projects they belong to. Only the Software Risk Manager user with admin privileges will be able to create,
edit, update, or delete host information.
Click the Hosts icon in the navigation bar to open the Host Scopes page.

This page shows a list of global host scopes with the following information:

376
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

• FQDN
• Hostname
• NetBIOS Name
• IP Address
• MAC Address
• Operating System
• Environment
• Associated Projects. Click the project name to open the project page.

Note: There's a basic filter field to sort hosts along with advanced filter options. Also, you can use the
"View" button to select which columns to display (or hide).

Tasks include the following:

• Creating a host
• Editing a host
• Deleting a host
• Managing host scopes. Click the Manage Host Scopes button to access the following options:
• Importing host scopes
• Exporting host scopes

Editing a Host Scope

To edit a host scope:

1. Click the Hosts icon in the navigation bar to open the Host Scopes page.
2. Click the dropdown list icon located in the last column of each row.

3. Select Edit Host.

4. Make changes as necessary.

• Click the delete icon to delete an existing value.
• Click the value button to add a field.
5. Click OK to save the changes.

377
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Deleting a Host Scope

To delete a host scope:

1. Click the Hosts icon in the navigation bar to open the Host Scopes page.
2. Click the dropdown list icon located in the last column of each row.

3. Select Delete Host.

4. Click Delete to confirm.

Creating a Host Scope

To create a host:

1. Click the Hosts icon in the navigation bar to open the Host Scopes page.
2. Click Create Host.

3. Click the appropriate button to add values to the following fields.

• FQDN
• Hostname
• NetBios Name
• IP Address
• MAC Address
• Operating System
• Environment
4. Click OK to save.

For more information

For information on host scope and the hosts table, see the following topics:

• Host Scopes
• Hosts Table

378
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Host Scopes

A Host Scope is effectively just a set of projects that share host information with each other. A Host Scope
can be used to model a network where each project in a Host Scope contains vulnerability information for
a vulnerable application that is housed on a potentially vulnerable host. Alternatively, one can simply use
Host Scopes to isolate host information to particular sets of projects so that overlapping pieces of host
information between Host Scopes don't interact with each other during Host Normalization and Finding
Correlation. Each Host Scope can have multiple projects attached to them but each project can only be
linked to one Host Scope. See Host Scope Associations for more information on how to set up projects
with Host Scopes.
Click the Hosts icon in the navigation bar to open the Hosts page. Use the Hosts and Host Scopes buttons
to display the associated data.

Managing Host Scopes

By default, the Global Host Scope will be the only one available. However, you can create new Host
Scopes by clicking Add Host Scope.

379
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Enter a name and click Save to create your Host Scope.

Once a host scope has been created, you can Import, Export, or Delete it.

Clicking Import will allow you to import a custom set of host information into the Host Scope for which you
clicked Import. Software Risk Manager currently only supports importing hosts defined in a .json file.
Hosts are expected to be provided as JSON Objects of the form: field-type: [values...] SRM
currently supports the following field-types: Hostname, FQDN, NetBIOS Name, IP Address, MAC Address,
Operating System, Ports. Every value for a field type is simply a string, except for Ports, which is a special
case expecting each value to be another JSON Object with the following structure:

"Ports": {
"Port": <port_number>
"Protocol": <port_protocol>
"State": <port_state>
}

Note: The Import button for non-selected Host Scopes will be disabled by default as you can only import
hosts into the selected Host Scope.

Clicking Export will provide you a .json file containing all the normalized hosts in the Host Scope for
which you clicked Export. The structure of the .json file matches that of the structure required for
importing hosts into a Host Scope.
Clicking Delete will bring up a window allowing you to confirm that you would like to delete the relevant
Host Scope. Deleting a Host Scope will delete all normalized host information belonging to that Host
Scope. To delete a Host Scope, you will first need to delete any projects associated with that Host Scope.

380
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

You can confirm that you would like to delete the relevant Host Scope by clicking OK.

Hosts Table

Selecting a Host Scope in the Host Scope management menu will populate the Hosts Table with
normalized host information from the selected Host Scope. Normalized hosts are sets of hosts reported by
different tools that are correlated to each other. Thus the information that the table is populated with is an
aggregation of the host information from various tools that are referencing the same host.

Viewing Host Information

Each row in the table contains all of the host information that Software Risk Manager is aware of for a
particular host, and each column in the table is a set of values appropriate for a particular field of interest.
Currently, Software Risk Manager only displays FQDN, NetBIOS Name, IP Address, MAC Address,
Operating System, Open Ports, Environment, and Associated Projects.

381
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Click View in the top right corner and use the toggles to select what information to display.

Manually Adding and Editing Hosts

Software Risk Manager allows you to manually add new hosts to the selected Host Scope. The Create
Host button is to the top right of the Hosts Table.

Clicking on it will bring up an interactive table where you can define the host that you are adding.

Clicking Add Value will produce a text field where you can enter a new value for the column you're editing.
Note that a default value will be shown if the text field is empty and serves as an example of a valid value.

There is some validation applied to IP Address, MAC Address, and Open Ports. Typing in an invalid value
for that field will cause the text field to be highlighted in red. Each invalid value is considered non-existent
when clicking OK to create a Host with the specified values, and consequently will not appear in the Hosts
Table when a host with invalid values is successfully created.
If you do not wish to include a value on a host, you may click the trash bin located at the far right of the cell
to delete the value from consideration.

382
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

You can include any number of values for any particular column in the editor. Note that Associated Projects
is not present in the editor. This is because Associated Projects is a derived field, found by determining if a
host exists in a particular project. Also note that any columns that are missing in the Hosts Table as a
consequence of disabling them in the "View" menu will still be shown while editing the hosts.
Software Risk Manager also allows you to manually edit existing normalized hosts in the Hosts Table. If
you click on the button in the right most column of the Hosts Table, a drop down menu will appear. The first
element in the drop down menu is "Edit Host".

Clicking on "Edit Host" will bring up the same interactive table that appears when you're manually adding a
new host, except now you will see it in the table, as opposed to above it.

Software Risk Manager also allows you to delete existing normalized hosts. In the same drop down menu
that "Edit Host" appears, you will also see "Delete Host".

Clicking on it will prompt you with a message detailing the consequences of deleting a host.

You may confirm the delete by clicking the "Delete" button. Clicking Cancel will bring you back to the Hosts
Table without deleting the host. Note that only the normalized host is deleted when clicking Delete. No host
information acquired from results during an analysis will be lost.

383
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

When creating or editing a host, you may end up introducing values for field-types that Software Risk
Manager considers "identifying". Identifying fields for Hosts are the FQDN, Hostname, NetBIOS Name, IP
Address, and MAC Address fields. If you introduce a value for an "identifying" field-type and it already
exists on a host in the current Host Scope, clicking on "OK" will cause the editor to expand to include two
new non-interactive tables.

The first new table will show you the host you tried to add, and the second new table will show you all
hosts that already have some of the values for "identifying" field-types the host you tried to add has.
Clicking Merge will cause the host you tried to add to be joined together with the other hosts that shared
values for "identifying" field-types with that host. Clicking Cancel will bring you back to the editor and will
not join the host with any other hosts. Note that you will be unable to edit the host you're trying to add until
you either click Merge or Cancel.

Filtering Hosts
Software Risk Manager also allows you to filter the hosts that appear in the Hosts Table. Above the table,
you should see a text field.

This is the "Generic" filter. Any value provided here will be used to display only hosts for which at least one
field value for any of the field-types satisfies the filter defined by the provided value.
Clicking advanced, which is next to the "Generic" Filter, will bring up the Advanced Filters sidebar.

384
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

These filters are specific to a host field-type, and providing a value for any of these will display only hosts
in the table for which the specified value exists in the specified column for that host. Note that each filter
available will only filter by one value, so attempting to filter by multiple values for a particular field-type (or
in the "Generic" filter) won't work.

Visual Log

The Visual Log page provides a helpful UI for certain events and errors that administrators might be
interested in for auditing purposes. It is important to note that the log file generated by a running Software
Risk Manager installation is not the same as the visual log. Most notably, arbitrary exceptions that appear
in the log file will typically not appear on the Visual Log page.
Click the "gear" icon in the header bar and select Visual Log to open the Visual Log page.

385
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

For information on log messages and filters, see the following topics:

• Visual Log Messages

• Visual Log Filter

Visual Log Messages

An entry in the visual log contains several useful parts:

• Type is an identifier for the type of event that the entry describes. The entry's type can be used as a
filter criteria (explained below).
• Title is a brief description of the event.
• Timestamp indicates when the event happened. The default display mode for this is " ago", but

386
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

hovering the mouse over the timestamp will reveal the precise date and time of the event.
• Expand/Collapse can be clicked to expand or collapse the log entry. By default, all log entries are
collapsed. You can actually click anywhere in the colored title area to expand or collapse the log entry.
• Body a longer-form description of the event. In some cases, it may be the same as the title.
• Identifying Info points out the Project and User associated with the event, if applicable. For example, a
login attempt for a Software Risk Manager user would be associated with that user. An analysis failure
event would be associated with the Project for which the analysis failed.
• Metadata is unstructured information related to the event. In the example shown above, the IP
Address, Login Method, and Reason are all metadata specific to the failed-loginevent type. Other
event types can (and typically will) have different metadata fields.
• Actions refer to the bar at the bottom of an expanded event, containing one or more buttons.
• The Dismiss button will cause the entry to become "dismissed," which will hide the event from view
by default when visiting the page later.
• The Retry button will be available for some error-type events, allowing users to retry whatever
process whose failure generated the log entry.

As noted in reference to the Timestamp, the visual log is ordered in reverse-chronological order, so that
the newest events will be at the top. As you scroll through the log, you'll eventually encounter a Load More
button that will load the next portion of the log. You can keep scrolling and clicking Load More until you
reach the end of the log (the earliest event). While you are on the Visual Log page, if new events happen,
rather than interrupting your view of the log by immediately appearing and altering the UI, a notification will
appear at the top of the page, prompting you to reload the log.

Dismissed Entries
Clicking Dismiss on a visual log entry will "dismiss" it, sending it into a semi-ignored state.
Once a reload is triggered (e.g., by refreshing the page, clicking the "click to reload" prompt, changing filter
states, or changing view menu settings), dismissed entries will be hidden from view (assuming the Include
dismissed log entries setting in the View menu is switched off). The Include dismissed log entries setting in
the View menu can be toggled to show or hide dismissed log entries, causing them to appear with the
checkered background style.

Visual Log Filters

The Visual Log Page offers a filtering capability that allows users to easily select a subset of the log.

387
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

By default, the Log Filter section will contain a single blank filter block. Each filter block contains three
optional criteria:

• View only those log entries whose User is one of the users selected in the filter block.
• View only those log entries whose Project is one of the projects selected in the filter block.
• View only those log entries whose Type is one of the types selected in the filter block.

For example, you could set a filter in order to only view failed-login events where someone attempted
to log in as the "admin" user.

Clicking the Or... button below the filter will add an extra filter block, allowing you to set alternate criteria. In
the example below, the filter will select failed-login events related to the "admin" user, OR any event
related to "Project A" and the "John Doe" user.

388
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

Note: Although all log types will be available for selection in the filter, those types may not always be
present in the log. For example, non-admin users will only be allowed to view log events that are directly
related to a project they manage, so they inherently won't be able to see failed-login events, for
example, because those events are never associated with projects. Also, the successful-login event
is not recorded by default. See the Visual Log Configuration section in the install guide to enable
recording of that event type.

Webhooks

Webhooks will allow SRM to issue POST requests to an external resource when finding or triage statuses
are updated. Currently, webhooks are an API-only feature. Please see the Webhooks section of the API
guide for more detailed information on how to configure webhooks.
Once a webhook has been configured, anytime the triage or finding status has been updated for one or
more findings that belong to a project that matches a webhook configuration, a payload will be generated
and a POST request will be made. The payload is a json object with the following properties:

• trigger – The event that triggered this payload to be sent.

• reasons – A list of reason objects detailing why the event was triggered. These objects may have the
following properties:
• reason – A short text describing the type of reason, can be one of the following: "analysis", "re-

389
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager User Guide

correlation", "archival", "system", "user-action", or "jira-sync".

• user – An object detailing the user that triggered this event. Contains the ID and name of the user.
Only available on "analysis", "re-correlation", "archival", and "user-action" reasons.
• analysisId – The ID of an analysis. Only available on "analysis" reasons.
• input – The name of an analysis input. Only available on "archival" reasons.
• action – A short text description providing context to the reason. Only available on "jira-sync",
"user-action", and "system" reasons.
• findings – A list of finding objects. See the Finding Table Data endpoint in the API guide to view the
structure of the finding objects.

If a webhook is configured to use a secret, the requests made by SRM will contain the X-Signature
header. The value of this header is generated by hashing the request json body using an HMAC hex
digest.

390
Software Risk Manager Documentation (v2025.3.5)

2
Software Risk Manager Install Guide
Software Risk Manager Install and Deployment Options

The full range of Software Risk Manager functionality is based on how it is deployed. This section provides
an overview of what each deployment provides.
Software Risk Manager has four deployment options, which are described below.
Native Installer
The native installer (also referred to as the "stand alone" deployment) is available for both Windows and
Linux. It provides an easy way to install the entire technology stack on a single server with an easy-to-use
UI and command line wizard. This deployment is recommended for users who want to get up and running
quickly and for simple maintenance and upgrades.
With the native installer, both the web application and database are running on the same system, which
can cause contention. For high availability, the Kubernetes deployment is recommended. In addition, the
native installer does not support running an external database, nor does it support horizontally scaling the
running of tools. For more information, see Running the Native Installer.

Note: Tool Orchestration and Scan Farm modules are not supported with this deployment option.

Docker Compose Deployment

This deployment is recommended for users who want to leverage containers while having everything on a
single server. (Note that the database can also be deployed on a seperate server). This deployment option
allows for using a bundled database or an external one. For more information, see Installation Using
Docker Compose.

Note: Tool Orchestration and Scan Farm modules are not supported with this deployment option.

Kubernetes Deployment
This deployment option is recommended for high availability and scalability. Kubernetes also supports Tool
Orchestration and Scan Farm modules. For more information, see Installation Using Kubernetes.
Manual Installation
This deployment is reserved for advanced administrators who want total control of the deployment. It
allows the user to install the web server and database and manage that infrastructure independently. The
database can be deployed on the same machine or a separate one from the web application. This
deployment method is not recommended due to its complexity and being prone to error.

391
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Note: Tool Orchestration and Scan Farm modules are not supported with this deployment option.

Installation Requirements for the Native Installer

The Native Installer has the following requirements.

Software Requirements
Software Risk Manager is pre-packaged with most of its requirements. There are, however, certain
prerequisites for installations that will be leveraging the .NET scanning support of Software Risk Manager.

Note: The bundled Dependency-Check periodically updates its database of vulnerabilities. If Software
Risk Manager is installed in an environment without a connection to the internet, this update will not
succeed. For more information, see the Internet Access section.

.NET Analysis
In order to run the bundled .NET tools supported by Software Risk Manager, the .NET Framework runtime
is required for Windows and the Mono runtime is required for Linux. Additionally, Dependency-Check
requires the .NET Core 8.0 SDK on all platforms.

Note: The .NET Core 8.0 SDK is preferred over the .NET Core 8.0 Runtime, as the Runtime may cause
Dependency-Check .NET analyses to fail in some environments.

Windows Users
It is recommended that the latest version of .NET be installed.
Software Risk Manager is capable of running multiple .NET analysis tools on your codebase. FxCop is a
supported tool and is developed and distributed by Microsoft. For Software Risk Manager to run FxCop on
your behalf, you must install it separately. Software Risk Manager will then automatically discover its
location and run it.
Software Risk Manager supports FxCop versions 10+ and will automatically discover the location of the
latest version of FxCop installed on your machine. If you would like to provide a specific location, set the
fxcop.path property in the Software Risk Manager configuration file (codedx.props). FxCop is a
legacy analyzer that is no longer available through Microsoft. Starting with Visual Studio 2019 and .NET
5.0, FxCop is replaced with Microsoft Code Analysis (Roslyn) Analyzers.

392
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Hardware Requirements
Hardware requirements vary, depending on how many Software Risk Manager projects will be active at the
same time, how frequently analyses will be conducted, whether built-in tools are being used, the number of
results from tools in use, how many concurrent users are expected to use the system, and what other
system interactions might be setup. However, the following is the suggested hardware configuration
requirements based on deployment size.
Table 1.
Deployment Size CPU Cores Memory IOPs Storage
Small
This configuration is recommended for
supporting up to 100 projects with
4 cores 16 GB RAM 3,000 250 GB
limited use of built-in tools, up to 1,000
analyses per day, and up to 8
concurrent analyses.

Medium
This configuration is recommended for
supporting between 100 and 2,000 8 cores 32 GB RAM 6,000 500 GB
projects, up to 2,000 analyses per day,
and up to 16 concurrent analyses.

Large
This configuration is recommended for
supporting between 2,000 and 10,000 16 cores 64 GB RAM 12,000 1 TB
projects, up to 10,000 analyses per day,
and up to 32 concurrent analyses.

Extra Large
This configuration is recommended for
supporting over 10,000 projects, more 32 cores 128 GB RAM 24,000 2 TB
than 10,000 analyses per day, and up to
64 concurrent analyses.

Operating Systems Supported

The following operating systems are supported:

• Windows (10, 11, and Server 2016+)

• Linux (Ubuntu 18+, RHEL/CentOS 7+)

393
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Installation Using the Native Installer

This section describes the Software Risk Manager native installer. For Docker or Kubernetes installation
instructions, please see the codedx-docker and srm-k8s pages respectively.

Note: A Kubernetes-based installation is necessary when using Tool Orchestration or Scan Service
(needed to run Coverity and Black Duck scans).

The Software Risk Manager installer is self-contained as it includes all of the software necessary to run
Software Risk Manager and is dependent upon its own Tomcat, Apache, and MariaDB services. The
services automatically start whenever Software Risk Manager is restarted.

Note: While multiple Software Risk Manager installations are supported, it is discouraged to run them on
the same machine. This will likely lead to resource contention, resulting in performance degradation in
those installations.

Some of the Software Risk Manager dependencies listen for network activity (e.g., the web server to
accept incoming requests). If a port conflict is detected, you will be prompted with a suggested alternate
port. It is your choice to accept that port or change it.
When first starting the installer downloaded for your platform, you should see the following screen.

394
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next and select whether this is a fresh install or an upgrade.

395
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

Linux Considerations

For headless Linux environments, the installer comes with an option to interact from the command line. To
do so, run the installer with the --mode text option.
For example:

./srm-<version>-linux-x64-installer.run --mode text

where you substitute the installer version number for "version."

The installer behaves differently depending on whether it is executed by the root user (or with sudo
privileges) or by a standard user. The default directories will change and the port numbers used for the
installation will also be different (port 80 for HTTP access for instance when using the root user vs. port
8080 for non-root users). For production installations, we strongly recommend triggering the installer with
root/sudo privileges.
By default, Software Risk Manager does not automatically start up on Linux systems. In order to have
Software Risk Manager start and stop cleanly when the system boots and shuts down, several commands
need to be executed depending on distribution.

396
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Note: Running on start up is only supported for root installations and assumes commands are run with
root privileges.

Run on Start Up for Debian-based Distributions

Copy ctlscript.sh to the /etc/init.d directory and name it codedx. ctlscript.sh can be found
in the Software Risk Manager installation folder. By default this will be in /opt/srm.

cp installdir/ctlscript.sh /etc/init.d/codedx

Then make the script executable.

chmod +x /etc/init.d/codedx

Add the following to the top of the codedx file below #!/bin/bash to ensure that the script is compatible
with systemd.

### BEGIN INIT INFO

# Provides: codedx
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start SRM services at boot time
# Description: Enable services required by SRM at startup.
### END INIT INFO

Enable the service to run by default

systemctl enable codedx

Following a reboot, Software Risk Manager should start automatically. To revert these changes, SRM can
be removed from the startup services with the following commands:

cd /etc/init.d
systemctl disable codedx

397
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Run on Start Up for RedHat-based Distributions

Copy ctlscript.sh to the /etc/init.d directory and name it codedx. ctlscript.sh can be found
in the Software Risk Manager installation folder. By default this will be in /opt/srm.

cp installdir/ctlscript.sh /etc/init.d/codedx

Replace the #!/bin/bash at the top of the file with the following:

#!/bin/bash
#
# chkconfig: 2345 80 30
# description: SRM services

Then install the script as a service.

chkconfig --add codedx

After a reboot, Software Risk Manager will start up automatically. To revert these changes, Software Risk
Manager may be removed from the startup services with the following command:

chkconfig --del codedx

Installation Directory

The Software Risk Manager installer places all its dependencies and program executables in the
installation directory. The installer will suggest a location on your file system that sticks with common
conventions for your adopted platform; however, you can choose to install Software Risk Manager to a
different location if needed.

398
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

Admin Account

Software Risk Manager has a built-in admin user to manage the system. The installer prompts you for the
credentials you want to use for that account. Be sure to keep note of these credentials in a secure location
as they are not retrievable once the admin user has been created. When new Software Risk Manager
releases are available, you will download and run the latest installer. Your installer admin credentials are
required to complete the installation.

Note: The first time you use Software Risk Manager, you must log in using the installer admin
credentials. After that, you can change the admin's password within Software Risk Manager; however,
changing the password in Software Risk Manager does not change the admin's password for the
installer.

399
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

Data Directory

Software Risk Manager stores data in the data directory you configure during the installation. The default
location is the typical place used by your adopted platform to place program data files. This can be
changed, if needed, from the relevant installer screen. For production installations of Software Risk
Manager, we strongly recommend that this data directory be part of your backup plan as it contains all data
managed by Software Risk Manager.

400
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

Protocol Configuration

Choose the protocol configuration for Software Risk Manager. The default is HTTP and HTTPS.

401
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

Web Server Ports

If you selected the default protocol (HTTP+HTTPS) on the previous screen, select which ports to use.

402
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

MariaDB Database Information

Enter a port for your MariaDB installation.

403
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

SSL Configuration

What you do with the SSL configuration depends on your deployment scenario. By default, the installer will
setup Software Risk Manager dependencies to offer both HTTP and HTTPS access to Software Risk
Manager. This is sufficient for most evaluation scenarios. If, however, you are deploying Software Risk
Manager for production usage, then we recommend that you use or obtain a valid SSL certificate for the
host machine. If you don't use your own certificates, HTTPS is enabled by default with a self-signed
certificate generated during installation. This will ensure secure communications to all clients accessing
Software Risk Manager. Note that if you use the default HTTPS option with the self-signed certificate, most
browsers will display a security warning when connecting, which will need to be accepted to proceed with
access to the site.
If Software Risk Manager will be used in a networked environment, using HTTPS to connect is
recommended. For example, once Software Risk Manager is installed, use https://<hostname>/srm
instead of http://<hostname>/srm (substituting in your machine's hostname).
Click the "Next" button if you're using the Software Risk Manager self-signed certificate. Otherwise, use
your own SSL certificate by getting the certificate and associated private key in PEM-encoded X.509
format. (Some issuers refer to this as “Apache format.”) Click "Do you want to import your own SSL
certificate?" and browse to those files.

404
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Replacing the SSL Certificate Post-Install

If you completed your installation using the Software Risk Manager self-signed SSL certificate (as shown
above), you can replace this self-signed certificate with your own SSL certificate. You might do this if you
skipped importing your own SSL certificate due to certificate failure and you now have a new SSL
certificate.
To replace the SSL certificate after Software Risk Manager installation:

1. Get your SSL certificate in PEM-encoded X.509 format (name the file server.crt) and the private
key for the certificate in PEM format (name the file server.key).
2. Copy the two files into the following directory: <your-srm-install-directory>/apache2/conf/
certs.
3. Restart your Software Risk Manager Apache service. You can do this in the manager app or in the
Services area on your control panel.

Generate an SSL Certificate

1. Enter the domain name for your Web Server to generate an SSL certificate.

405
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

2. Click Next to continue.

Trusting Certificates

If you're connecting with an application (such as Jira or Git) that is using a self-signed HTTPS certificate,
you will need to add it to the Software Risk Manager Java trust store, as explained below.

Getting Software Risk Manager to Trust Your Third-party

or Self-signed Certificate
Windows
1. Open a command prompt in administrator mode.
2. Change directory to the Software Risk Manager Java trust store: cd <installation-
directory>\Code Dx\java\bin where the <installation-directory> default is
C:\Program Files\Software Risk Manager.
3. Run keytool -printcert -rfc -sslserver <server hostname:port> | keytool
-importcert -keystore "../lib/security/cacerts" -storepass changeit -alias
<name for your server> -noprompt. Replace <server hostname:port> and <name for
your server> with the appropriate information for your environment.

406
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

4. Restart the Software Risk Manager services.

Linux
1. Open a terminal window.
2. Change directory to the Software Risk Manager Java trust store: cd <installation-
directory>/java/bin where the <installation-directory> defaults are /opt/srm/ for
Linux root and /home/srm/ for Linux non-root.
3. Import the key to the Software Risk Manager Java installation's keystore:
• [root] use ./keytool -printcert -rfc -sslserver <server hostname:port> | sudo
./keytool -importcert -keystore "../lib/security/cacerts" -storepass
changeit -alias <name for your server> -noprompt. Replace <server
hostname:port> and <name for your server> with the appropriate information for your
environment.
• [non-root] use ./keytool -printcert -rfc -sslserver <server hostname:port> |
./keytool -importcert -keystore "../lib/security/cacerts" -storepass
changeit -alias <name for your server> -noprompt. Replace <server
hostname:port> and <name for your server> with the appropriate information for your
environment.
4. Restart the Software Risk Manager services.

Deleting a Certificate from the Trust Store

1. Open a Windows command prompt in administrator mode or a terminal in Linux.
2. Change the directory to the Software Risk Manager Java trust store: cd <installation-
directory>/java/bin where the <installation-directory> defaults are C:\Program
Files\Software Risk Manager on Windows; /opt/srm for Linux root; and /home/srm/ for
Linux non-root. Replace <name for your server> with the appropriate information for your
environment.
• [Windows] use keytool -delete <name for your server> -keystore ../lib/
security/cacerts.
• [Linux root installation] use sudo ./keytool -delete <name for your server>
-keystore ../lib/security/cacerts.
• [Linux non-root installation] use ./keytool -delete <name for your server>
-keystore ../lib/security/cacerts.
3. Restart the Software Risk Manager services.

Tomcat Port Configuration

Enter the Tomcat configuration parameters you wish to use in the Tomcat AJP Port field.

407
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to continue.

Time Expectations

Software Risk Manager is now ready to install. Use the Back button to correct any configuration options.

408
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Click Next to begin the installation.

Installation may take several minutes depending on the hardware performance for the deployment
machine.

409
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

When the installation is complete, the Setup Wizard completion screen will appear.

410
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Select the Launch Software Risk Manager option to launch the applicaton after clicking the Finish button,
then Click Finish.

Firewall

Software Risk Manager is a web application that requires a web server to house it. The Apache web server
is provided and configured automatically with the installer. However, for most systems, this means that a
firewall exception is necessary to allow incoming connections over the network so that users (including
you) can access the installation from other machines. By default, the firewall ports that need to be opened
up are 80 and 443, for HTTP and HTTPS respectively.
On Windows, you will be prompted with the following alert in order to grant the firewall exception.

411
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Note: The first time you use Software Risk Manager, you must log in using the installer admin
credentials. After that, you can change the admin's password within Software Risk Manager; however,
changing the password in Software Risk Manager does not change the admin's password for the
installer.

License File

If you do not have a license or if your license has expired or is invalid, please request a license from our
Sales Team (see Requesting a License below).
When you purchase Software Risk Manager, you will receive (usually via email) a new license (a blob of
letters and numbers) that you will need to install.

Installing a New License

To install a new license, you must access the License Management page. If your license has expired or is
invalid, the License Management page will automatically open. Otherwise, you can open the License
Management page by clicking the license summary link at the top of the Admin page.
The image below shows the state of the page when you first arrive.

412
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

The header area provides the current license status. In this example, the license is valid, but if the license
has expired or is invalid, the header will show a message indicating what is wrong.
The form shown in the example above allows you to upload the license you received. Open your license
key file using any ASCII text editor (such as Notepad), copy the license text, and paste it in the Use a new
license form.
Click the Use this license button. If the license is valid, you will be sent to the Software Risk Manager
home page; otherwise, the License Management page will just reload.
If you require further assistance, please contact us.

Uninstallation or Reinstallation

Software Risk Manager is distributed with an uninstaller, which will remove the files and system services
that were setup for Software Risk Manager. You will be prompted with the choice of removing the data files
used by Software Risk Manager. Be aware that removing data files is irreversible and will result in data
deletion.
To reinstall Software Risk Manager, running the uninstaller first is recommended.

413
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Upgrading

During the upgrade process, the installer may present you with a list of issues. These issues must be
resolved to complete the process.
If you are performing an upgrade using the installer over SSH, it is recommended to use screen, tmux, or
similar to ensure the upgrade process will continue if the SSH session is disconnected.

Clean File System

The upgrade process expects only certain files and folders to exist in the installation location. If you are
presented with a list of files, do the following:

• Open the installation directory (e.g., C:\Program Files\Software Risk Manager or /opt/
srm/).
• Remove the specified files or folders but leave the backup folder (backup-<timestamp>), the
upgrade.ini file, and the properties.ini file.

Remove Services
On Windows, the upgrade process requires specific Software Risk Manager services. Other Software Risk
Manager services should be removed. If you are presented with a list of services, you can remove them by
doing the following:

• Open the “Command Prompt” application as an administrator.

• Remove the presented service:

> sc delete CodeDxMariaDB

[SC] DeleteService SUCCESS

Note: Replace CodeDxMariaDB with the service name that the installer displays.

Free Ports
The upgrade process requires certain ports to be available. If you are presented with a list of ports, you
can free them using the procedures shown below.

Windows
1. Open the “Resource Monitor” application as an administrator.
2. Click the “Network” tab.

414
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

3. Click the “TCP Connections” bar to see a list of TCP connections established.
4. Look for one of the ports in the presented list.

To continue with the upgrade process, you have to make sure that the presented ports are available. If the
process using the required ports is a version of Software Risk Manager, please follow the instructions in
the "Remove Services" section. If it is not related to Software Risk Manager, make sure to find the
conflicting program and ensure that the problem will not occur after installation.

Linux and OS X
List the processes listening to a TCP connection using terminal:

sudo lsof -iTCP:8009 -sTCP:LISTEN

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 81106 codedx 50u IPv4 40576813 0t0 TCP *:8009 (LISTEN)

Note: Only use sudo if installed as root.

To continue with the upgrade process, you have to make sure that the presented ports are available. You
should stop the process that spawned the service and ensure that the conflict will not occur after
installation.

Restoring to a Previous Version

In your backup folder, there’s a file called restore-backup, which is used to restore to a previous
version of Software Risk Manager.

Windows
1. Navigate to the backup folder, which is in the installation folder that you provided during installation.
The default folder is C:\Program Files\Software Risk Manager\backup-<timestamp>\
where <timestamp> is the date and time the upgrade was performed.
2. Right-click on restore-backup.bat and choose "Run as administrator."

Linux Root Installation

1. Navigate to the backup folder that was created during the upgrade process. The default folder is
/opt/srm/backup-<timestamp>/ where <timestamp> is the date and time the upgrade was
performed.
2. Open a terminal and run sudo chmod +x restore-backup.sh.
3. Run sudo ./restore-backup.sh.

415
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Linux Non-Root Installation

1. Navigate to the backup folder that was created during the upgrade process. The default folder is
/home/srm/backup-<timestamp>/ where <timestamp> is the date and time the upgrade was
performed.
2. Open a terminal and run chmod +x restore-backup.sh.
3. Run ./restore-backup.sh.

Manage Software Risk Manager Services

The Software Risk Manager installer includes a graphical tool to manage services, which can be found in
the Software Risk Manager installation folder. For Windows, the tool is called manager-windows; for Linux,
it's manager-linux-x64.run.
Open the appropriate tool and go to the Manage Servers tab to view and change the status of the services.
To start, stop, or restart individual services, highlight the service, then click the desired action (see the
screenshot below). Use the buttons on the bottom to change the status of all the services.
Alternatively, you can use the Windows Service Manager or the ctlscript shell files for Linux to change the
status of Software Risk Manager services. To start, stop, or restart any Software Risk Manager services
using ctlscript, navigate to the Software Risk Manager installation folder and follow the examples below:

• Start individual services (you can replace "start" with "stop" or "restart"):
• ./ctlscript.sh start tomcat
• ./ctlscript.sh start apache
• ./ctlscript.sh start mysql
• Start, stop, or restart all services:
• ./ctlscript.sh start
• ./ctlscript.sh stop
• ./ctlscript.sh restart
• Obtain the current status of all services:
• ./ctlscript.sh status

Installation Using Docker Compose

A Docker-based installation consists of two parts: the SRM web application Docker image and the
database upon which it depends. You can provide your own MariaDB or MySQL database instance or use
the provided MariaDB Docker image.
For more information about using Docker Compose, see the sections below:

• Software Risk Manager Core Deployments

• Docker Compose Requirements
• Configuration Tasks (Pre-work)
• Persistent Storage Pre-work
• External Web Database Pre-work
• Trust Certificates Pre-work

416
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

• HTTPS Pre-work
• Installation
• Installation Prerequisites
• Volume Naming
• Installation Without an External Database
• Installation With an External Database
• Customizing Software Risk Manager
• Backup and Restore
• Prerequisites
• Creating a Backup
• Backup Retention
• Restoring a Backup
• Upgrading Software Risk Manager
• Running Software Risk Manager After Upgrade
• Migrating from Software Risk Manager Installer to Docker Compose
• Migration Without an External Database
• Migration With an External Database
• Uninstall

Software Risk Manager Core Deployments

The footprint of your Software Risk Manager Docker-Compose deployment depends on whether or not you
plan to use an external database.
The Software Risk Manager web application requires a MariaDB (version 10.6.x) or a MySQL (version
8.0.x) database instance. You can provide a database instance or use what's included in the default
Compose file. An external database can be a standalone instance or one managed for you by a cloud
provider such as AWS or Azure.
A deployment using an external database consists of one Software Risk Manager Docker container for the
web application that depends on a Docker volume.
Figure 1. Core Deployment with an External Database

417
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

A deployment without an external database includes an additional Docker container for the Software Risk
Manager Web database instance. The MariaDB database instance stores data using a Docker volume.
Figure 2. Core Deployment without an External Database

418
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Docker Compose Requirements

Software Risk Manager deployment requires Docker Compose version 2.

System Size
Hardware requirements can vary based on a number of factors, including how many Software Risk
Manager projects will be active at the same time, how frequently analyses will be conducted, whether built-
in tools are being used, the number of results from tools in use, how many concurrent users are expected
to use the system, and what other system interactions might be configured. Taking that into account, you
can refer to the tables below for some general guidelines to help determine the size of your deployment.
Table 1.
Size Total Projects Daily Analyses Concurrent Analyses
Small 1–100 1,000 8
Medium 100–2,000 2,000 16

419
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Size Total Projects Daily Analyses Concurrent Analyses

Large 2,000–10,000 10,000 32
Extra Large 10,000+ 10,000+ 64

Core Feature Requirements

This section describes the web and web database requirements based on the system size.

Core Web Workload Requirements

Table 2.
Size CPU Cores Memory IOPs Storage
Small 4 16 GB 3,000 64 GB
Medium 8 32 GB 6,000 128 GB
Large 16 64 GB 12,000 256 GB
Extra Large 32 128 GB 32,000 512 GB

Core Web Database Workload Requirements

Table 3.
Size CPU Cores Memory IOPs Storage
Small 4 16 GB 3,000 192 GB
Medium 8 32 GB 6,000 384 GB
Large 16 64 GB 12,000 768 GB
Extra Large 32 128 GB 32,000 1536 GB

Core Persistent Storage Requirements

Table 4.
Volume Feature Description
Required volume for web
Web AppData Core
workload
Core (when not using external
DB Data Database volume for database
database)

420
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Core Internet Access Requirements

Software Risk Manager uses internet access in the background for some activities, such as keeping tool
data up-to-date and periodically checking for a new Software Risk Manager release.
Software Risk Manager does not require internet access; however, internet access is highly recommended
to ensure full functionality.
To disable background internet access by Software Risk Manager, customize your Software Risk Manager
deployment by setting codedx.offline-mode = true. The default is false. Note that this will not
disable any internet access that may occur due to user action or configuration settings, such as Tool
Connector, Git, or Issue Tracker configurations.
When internet access is enabled, Software Risk Manager will perform the following actions:

• Update notifications. Software Risk Manager will periodically check for newer versions and display an
update notification when one is available. Requests for the latest version are sent to
https://service.codedx.com/updates/latestVersionData.json.
• Dependency-Check updates. Dependency-Check will periodically download updates from the
National Vulnerability Database, the Retire.js repository, or reach out to Maven Central while scanning
Java dependencies (this aids in the dependency identification process, to cut down on both false
positive and false negative results).
• Offline mode. If Software Risk Manager is in offline mode, this may lead to lower quality results when
running Dependency-Check as a bundled tool.
• Secure Code Warrior. Unless noted elsewhere, Software Risk Manager will reach out to any URLs
belonging to the securecodewarrior.com domain.

Configuration Tasks (Pre-work)

The following sections specify configuration tasks that might apply to your deployment. Pre-work tasks
require updates to your Docker Compose file.

• If you are not using an external database, you will edit docker-compose.yml.
• If you are using an external database, you will edit docker-compose-external-db.yml instead.

For more information, see the following sections:

• Persistent Storage Pre-work

• External Web Database Pre-work
• Trust Certificates Pre-work
• HTTPS Pre-work

Persistent Storage Pre-work

Software Risk Manager depends on one or more Docker volumes. When using selinux, you must append
:Z to volumes listed in your Docker Compose file, including the default volumes and any extra volumes
added during configuration tasks.

421
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

External Web Database Pre-work

Software Risk Manager includes a MariaDB database that requires no configuration on your part, so you
can skip this section if you do not plan to use an external database instance.
Your MariaDB/MySQL database must be on port 3306.
If you prefer an external database, the web workload supports MariaDB version 10.6.x and MySQL version
8.0.x. Complete the configuration tasks shown below before installing Software Risk Manager with an
external web database.
Your MariaDB/MySQL database must include the following variable configuration:

• optimizer_search_depth=0
• character_set_server=utf8mb4
• collation_server=utf8mb4_general_ci
• lower_case_table_names=1
• log_bin_trust_function_creators=1

The log_bin_trust_function_creators parameter is required when using replication (sometimes

enabled by default).
If you are using a database instance hosted by AWS, Azure, or GCP, refer to the following:

• How to create a new AWS parameter group

• How to configure Azure Database for MySQL parameters
• How to configure GCP Cloud SQL MySQL database flags.

Refer to the Web Database Workload Requirements section for database instance configuration details.
To create the database catalog and Software Risk Manager database user:

Note: If you have to reinstall Software Risk Manager and delete your Software Risk Manager data, you
must repeat steps 2 and 3 below after deleting your Software Risk Manager Docker volume.

1. Create a database user.

You can customize the following statement to create a user named "srm." Remove REQUIRE SSL
when not using TLS (your database instance may require security transport).
CREATE USER 'srm'@'%' IDENTIFIED BY 'enter-a-password-here' REQUIRE SSL;
2. Create a database catalog.
The following statement creates a catalog named srmdb:
CREATE DATABASE srmdb;
3. Grant required privileges on the database catalog to the database user you created.
The following statements grant permissions to the srm database user.
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, CREATE TEMPORARY TABLES,
ALTER, REFERENCES, INDEX, DROP, TRIGGER ON srmdb.* to 'srm'@'%'; FLUSH

422
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

PRIVILEGES;

If your database configuration requires Software Risk Manager to trust a certificate (e.g., the Amazon RDS
root certificate), follow the Trust Certificates instructions to trust your database certificate and update the
volumes section of your docker-compose-external-db.yml file.

Trust Certificates Pre-work

Your Software Risk Manager instance can trust self-signed certificates or certificates issued by certificate
authorities that are not trusted by default. Obtain a copy of the cacerts file from a Java 11 distribution,
which will include the keytool program that you will need to run the following command:

keytool -import -trustcacerts -keystore ./cacerts -file /path/to/cert -alias

cert-name

Note: The default password for a Java cacerts file is changeit.

You can mount your cacerts file by adding a line to the volumes list in the codedx-tomcat section:

codedx-tomcat:
...
volumes:
- codedx-appdata:/opt/codedx
- /path/to/cacerts:/opt/java/openjdk/lib/security/cacerts
...

Note: Append :Z to the extra volume mount when using selinux.

HTTPS Pre-work

The Tomcat container can support HTTPS. For example, generate a self-signed certificate with openssl
or obtain a real certificate from a certificate authority:

openssl req -new -newkey rsa:4096 -days 3650 -nodes -x509 -subj "/C=US/ST=Ne
w York/L=Northport/O=Software Risk Manager/CN=localhost" -keyout ./ssl.key
-out ./ssl.crt

423
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

The server.xml file contains a configuration that supports HTTPS using Tomcat's SSL/TLS capability .
This template can be mounted over the existing server.xml in the Docker image. The SSL certificate
and private key must also be mounted.
Update the codedx-tomcat section in your Docker Compose file (either docker-compose.yml or
docker-compose-external-db.yml) with SSL and server.xml volume mounts, switching ports
from 8080:8080 to 8443:8443. See what follows for Docker Compose file content using port 8443 with
extra volume mounts for server.xml, ssl.key, and ssl.crt.

codedx-tomcat:
...
volumes:
- codedx-appdata:/opt/codedx
- /path/to/ssl.crt:/usr/local/tomcat/conf/ssl.crt
- /path/to/ssl.key:/usr/local/tomcat/conf/ssl.key
- /path/to/server.xml:/usr/local/tomcat/conf/server.xml
ports:
- 8443:8443
...

Note: Append :Z to the extra volume mount when using selinux.

Software Risk Manager Installation

This section details how to start a functional instance of Software Risk Manager using Docker Compose.
Installation instructions will vary based on whether or not you are using an external database. Complete
the required pre-work configuration tasks before continuing with either the no-external-database or
external-database installation path.

• Installation Prerequisites
• Volume Naming
• Installation without an External Database
• Installation with an External Database

Installation Prerequisites

Before installing Software Risk Manager, you must install the following:

1. Install Docker using these instructions.

2. Install docker-compose.

424
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Volume Naming

When creating named volumes, Docker Compose will prepend the project name, which is the current
directory name by default, to the volume name. In other words, if you have a Docker Compose install
under the folder srm-docker and another under srm-docker-2, their volume names will be distinct and
contain different data. Without specifying the -p option, the following two named volumes would exist:

• srm-docker_codedx-appdata-volume
• srm-docker-2_codedx-appdata-volume

Named volumes are created when doing docker-compose up, so if you want to override the default
naming, you need to specify a project name the first time you execute the following command:

docker-compose -p srm -f ./docker-compose.yml up

Installation without an External Database

The docker-compose.yml file is used to install Software Risk Manager without an external database.
To install Software Risk Manager without an external database:

1. Select a password for the MariaDB root user, one that does not use single quote characters, and edit
your docker-compose.yml file by specifying the password for both the MARIADB_ROOT_PASSWORD
and DB_PASSWORD parameters.
2. Select a password for the Software Risk Manager admin user and edit your docker-compose.yml
file by specifying the password for the SUPERUSER_PASSWORD parameter.
3. Run docker-compose -f ./docker-compose.yml up -d to start the SRM Docker containers.
4. Run docker-compose -f ./docker-compose.yml logs -f to view log data.
When the message "The Server is now ready!" appears in the console, you can navigate to either
http://hostname:8080/srm or https://hostname:8443/srm (depending on your HTTPS configuration) to
log into your Software Risk Manager instance.

• To stop, run docker-compose -f ./docker-compose.yml stop.

• To remove the Docker containers automatically created, run docker-compose -f ./docker-
compose.yml down.

Note: If you want to migrate data from an existing Software Risk Manager system, refer to these
instructions.

Installation with an External Database

To install Software Risk Manager with an external database:

1. Select a password for the Software Risk Manager admin user and edit your docker-compose-

425
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

external-db.yml file by specifying the password for the SUPERUSER_PASSWORD parameter.

2. Edit the docker-compose-external-db.yml file by appending
&useSSL=true&requireSSL=true to the DB_URL parameter.
3. Edit the docker-compose-external-db.yml file as follows:
a. Enter the database username for the DB_USER parameter.
b. Enter the database password for the DB_PASSWORD parameter.
c. Update the DB_URL parameter by specifying your database instance hostname.
d. Update the DB_URL parameter by specifying your Software Risk Manager database name (e.g.,
"srmdb").
The following is an example of a DB_URL parameter value using hostname db-hostname and
database name srmdb:

"jdbc:mysql://db-hostname/srmdb?sessionVariables=sql_mode='STRICT_TRAN
S_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'"

If you followed the steps required for secure transport, your connection string will look like the
following:

"jdbc:mysql://db-hostname/srmdb?sessionVariables=sql_mode='STRICT_TRAN
S_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'&useSSL=tru
e&requireSSL=true"

4. Follow the HTTPS instructions if your deployment requires TLS/SSL.

5. Start Software Risk Manager with the following command:

docker-compose -f ./docker-compose-external-db.yml up -d

You can run the following commands to view Software Risk Manager log data (assumes an srm-
docker-codedx-tomcat-1 container name):

docker exec srm-docker-codedx-tomcat-1 tail -f /opt/codedx/log-files/code

dx.log
docker logs srm-docker-codedx-tomcat-1

Note: If you want to migrate data from an existing Software Risk Manager system, refer to these
instructions.

Customizing Software Risk Manager

You can customize Software Risk Manager's behavior by specifying certain configuration properties.

426
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Custom Props
Software Risk Manager features can be customized through the configuration file codedx.props which,
by default, is located in your Tomcat container at /opt/codedx. (A full list of configuration parameters
and how to change them can be found in the section on using the native installer.)
For example, to automatically sign a user out after 15 minutes of inactivity (20 minutes by default), set
session.lifetime to 15 minutes.
To set the sign-out property in a Docker Compose install:

1. With Software Risk Manager up and running, copy its codedx.props file to your current working
directory using the following docker cp command, replacing the srm-docker-codedx-tomcat-1
Docker container name as necessary (you can list running Docker containers with docker ps):

docker cp srm-docker-codedx-tomcat-1:/opt/codedx/codedx.props .

2. Edit your local codedx.props file by appending the following line:

session.lifetime = 15 minutes

3. Copy codedx.props back to its original location, replacing the srm-docker-codedx-tomcat-1

Docker container name as necessary:

docker cp codedx.props srm-docker-codedx-tomcat-1:/opt/codedx/codedx.prop

s

4. Restart the SRM web container by running the Docker Compose down and up commands that you
use for your deployment.

Custom Context Path

By default, Software Risk Manager is accessible at /srm. For backward compatibility, requests to
/codedx/api and /codedx/x will be rewritten to /srm/api and /srm/x respectively, and requests to
/codedx will be redirected to /srm.
You can change the Software Risk Manager context path by setting the SRM_WEBAPP_NAME
environment variable in your Docker Compose file. The following example changes the default context
path from /srm to /mysrm:

codedx-tomcat:
image: ...
environment:

427
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

DB_URL: ...
SRM_WEBAPP_NAME: "mysrm"

With this configuration, you can access Software Risk Manager at hostname/mysrm after restarting
Software Risk Manager. URL rewrites and redirects from /codedx become disabled when using a custom
context path.

Backup and Restore

This section explains how to back up and restore Software Risk Manager using backup.ps1 and
restore.ps1 in the scripts directory. Both scripts include a -p project name parameter that you
should specify if you used a project name with your Docker Compose up command.
The backup script creates a new volume named codedx-backups where each backup gets stored by
name. You can either specify a name or let the backup script generate a name for you formatted as
backup-{date}-{time}.

Note: Be cautious of commands such as docker volume prune. The volume storing Software Risk
Manager backups is not attached to a container and would be deleted.

For more information, see the following sections:

• Backup and Restore Prerequisites

• Creating a Backup
• Backup Retention
• Restoring a Backup

Back Up and Restore Prerequisites

The Software Risk Manager backup and restore scripts depend on PowerShell Core, which can be
installed on macOS, Linux, and Windows.
When running the backup and restore scripts, make sure you're either in a PowerShell Core terminal
environment or the command begins with pwsh so it's run by PowerShell Core.
Windows Prerequisites
Ensure you can run PowerShell Core scripts on Windows by switching your PowerShell Execution Policy
to RemoteSigned (recommended) or Unrestricted. You must run the Set-ExecutionPolicy
-ExecutionPolicy RemoteSigned command from an elevated/administrator Command Prompt.

Creating a Backup

Backup instructions will vary based on whether or not you are using an external database. Use the
procedures shown below to create a backup that will include the volume data for your deployment under

428
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

the name my-srm-backup.

Backup without an External Database

To create a backup without an external database:

1. Stop your containers using the Docker Compose down command for your deployment.

docker-compose -f /path/to/your-docker-compose-file down

2. Open a terminal window and change the directory to your srm-docker GitHub repository.

cd /path/to/srm-docker

3. Run the backup.ps1 script by specifying a backup name (e.g., my-srm-backup) and the path to
your Docker Compose file.

pwsh ./scripts/backup.ps1 -BackupName my-srm-backup -ComposeConfigPath /p

ath/to/your-docker-compose-file

Note: Specify a project name using the -p parameter, if necessary.

4. Verify that you see the following message indicating a successful backup:

Successfully created backup <backup-name>

Backup with an External Database

To create a backup with an external database:

1. Stop your containers using the Docker Compose down command for your deployment.

docker-compose -f /path/to/your-docker-compose-file down

2. Open a terminal window and change the directory to your srm-docker GitHub repository.

cd /path/to/srm-docker

429
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

3. Run the backup.ps1 script by specifying a backup name (e.g., my-srm-backup), the path to your
Docker Compose file, and the name of your web volume (you can list volumes with the docker
volume ls command).

pwsh ./scripts/backup.ps1 -BackupName my-srm-backup -AppDataVol srm-docke

r_codedx-appdata-ex-db-volume -ComposeConfigPath /path/to/your-docker-com
pose-file

Note: Specify a project name using the -p parameter, if necessary.

4. Verify that you see this message indicating a successful backup:

Successfully created backup <backup-name>

5. Back up your external database.

Backup Retention

Backups will be automatically removed by the backup script if they meet one of the following criteria:

• Older than 30 days. The 30-day default can be changed with the -Retain backup script parameter,
using -Retain 0 to ignore backup age, -Retain 5 for 5 days, and -Retain 10:00 for 10 hours of
retention.
• Exceeds maximum backup count. By default, a maximum of 10 backups will be stored at a time. This
can be configured with the -MaximumBackups backup script parameter.

For more advanced usages of the backup script, such as setting the names of your Tomcat and DB
containers if they are not the default, see the help info via the following command run from the srm-docker
directory:

pwsh -Command get-help .\scripts\backup.ps1 -full

Restoring a Backup

You can use the included restore.ps1 script in your srm-docker/scripts folder to restore a backup
created by backup.ps1. This will restore Software Risk Manager data from a provided backup name that
was either specified or generated when creating the backup.
To restore a backup:

1. Stop your containers using the Docker Compose down command for your deployment to avoid
unexpected restore behavior.

430
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

2. Run the following command to restore a backup by entering its name from the list of backups:

pwsh ./scripts/restore.ps1

Note: You can use the -BackupName parameter to skip the backup list by specifying a specific
backup.

3. Verify that you see the following message indicating a successful restore:

Successfully restored backup <backup-name>

4. If you are using an external database, restore the related database backup now.

The restore command assumes no defaults have been changed about the Software Risk Manager Docker
Compose environment. If defaults were modified or for more advanced usages of the restore script, see
the help information provided by running the following command from the srm-docker directory:

pwsh -Command get-help .\scripts\restore.ps1 -full

Upgrading Software Risk Manager

This section details how to upgrade Software Risk Manager to the latest version.

Note: It is recommended that you create a backup of your Software Risk Manager Docker Compose
environment before upgrading to the latest Software Risk Manager version.

Remove your Software Risk Manager container(s) before starting the upgrade. (Do not use the -v switch
with the down command because it will delete your data volumes.)

docker-compose -f /path/to/your-docker-compose-file down

The recommended upgrade method is to pull the latest changes from GitHub. The Docker Compose file is
updated with each Software Risk Manager release to reference the latest Docker image versions. Edits to
local files, such as your Docker Compose file, may block your pull from GitHub, so use the following
commands to stash your changes and reapply them after your pull:

cd /path/to/srm-docker
git stash save before-upgrade

431
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

git pull
git stash apply

If you see a "Merge conflict" message when you run git stash apply, edit the flagged file to resolve
the conflict, then run git add /path/to/file to mark the file as merged.
If you do not want to use Git, you can alternatively download the latest ZIP file from GitHub. (If you use the
ZIP to replace an existing folder, you must reapply any local edits, such as the changes you made to your
Docker Compose file.)
Once you have the latest changes, run your Docker Compose up command to start Software Risk
Manager:

docker-compose -f /path/to/your-docker-compose-file up

Running Software Risk Manager After Upgrade

After successfully upgrading, you can run the following command to see the effects of the upgrade:

docker-compose -f /path/to/your-docker-compose-file up

Pulling the latest files via Git ensures that you update your original files with the latest versions. Running
your Docker Compose commands with the upgraded files from the same directory avoids unexpected
behavior due to how docker-compose sets project names.

Migrating from the Software Risk Manager Native Installer to Docker Compose

Refer to the sections below to migrate your data from a system created by the Software Risk Manager
Installer to your Docker Compose instance. The version you are running with Docker Compose must equal
the version number of the system whose data you want to migrate. If necessary, upgrade your systems to
a matching version.

Prerequisites
The Software Risk Manager migration script depends on PowerShell Core, which can be installed on
macOS, Linux, and Windows. However, the target system you're migrating data to should have
successfully gone through the installation process.

Windows Prerequisites
Ensure you can run PowerShell Core scripts on Windows by switching your PowerShell Execution Policy
to RemoteSigned (recommended) or Unrestricted. You must run the Set-ExecutionPolicy

432
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

-ExecutionPolicy RemoteSigned command from an elevated/administrator Command Prompt.

Migration Paths
For more information on migration, see the following:

• Migration Without an External Database

• Migration With an External Database

Migration Without an External Database

The following steps cover migrating data from a Software Risk Manager system installed with the native
installer to an existing Docker Compose deployment.
To migrate data from a Software Risk Manager system installed using the native installer:

1. Verify that your Software Risk Manager deployed with Docker Compose is running.
2. Verify that your Software Risk Manager deployed with the native installer is running.
3. Verify that the version numbers of both systems match.
4. Log on to your source Software Risk Manager server whose data you want to migrate.
5. Run mysqldump to create a backup file. You can run the following command to create a dump-
srm.sql file after specifying the parameters that work for your database.

mysqldump --host=127.0.0.1 --port=3306 --user=root -p codedx -r dump-sr

m.sql

Note: The above command uses a database named codedx. Older versions of Software Risk
Manager may use a database named bitnami_codedx.

6. You may encounter an issue running SRM if the database dump file makes use of DEFINER. Run the
following command with dump-srm.sql replaced with the path of your database dump file. This will
overwrite the existing database dump file with the definers removed.

(Get-Content "dump-srm.sql") -replace '\sDEFINER=`[^`]*`@`[^`]*`','' | Ou

t-File dump-srm.sql

7. Locate the directory path for your Software Risk Manager AppData directory (e.g., /path/to/
codedx_data/codedx_appdata). The AppData directory contains your analysis-files and log-files
directories.
8. Copy your database dump file and Software Risk Manager AppData directory to the system running
Software Risk Manager with Docker Compose.
9. Return to the system running Software Risk Manager with Docker Compose, change directory to this
repository (srm-docker folder), and run the migrate-data.ps1 script with the following commands.

433
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

When prompted, enter the path to your dump-srm.sql file, your Software Risk Manager AppData
directory, and specify the password for the Docker Compose root database user.

cd /path/to/srm-docker
pwsh ./admin/migrate-data.ps1

Note: The above command will use the default values for the script parameters
-tomcatContainerName (srm-docker-codedx-tomcat-1), -dbContainerName (srm-docker-
codedx-db-1), and dbName (codedx). You can find your Docker container names by running docker
ps.

Your script output should look similar to the following:

pwsh ./admin/migrate-data.ps1
Enter the path to your mysqldump file: /path/to/dump-srm.sql
VERBOSE: Checking database dump file path...
Enter the path to your Software Risk Manager AppData folder: /path/to/cod
edx
VERBOSE: Checking appdata path...
VERBOSE: Checking appdata/analysis-files path...
Enter the password for the docker MariaDB root user: **********
VERBOSE: Checking PATH prerequisites...
VERBOSE: Checking running containers...
VERBOSE: Dropping database named codedx...
VERBOSE: Creating database named codedx...
VERBOSE: Creating temporary directory...
VERBOSE: Copying database dump file to container...
VERBOSE: Importing database dump file (may take a while)...
VERBOSE: Deleting database dump file...
VERBOSE: Deleting directories...
VERBOSE: Deleting directory /opt/codedx/analysis-files...
VERBOSE: Deleting directory /opt/codedx/keystore...
VERBOSE: Deleting directory /opt/codedx/mltriage-files...
VERBOSE: Copying directories...
VERBOSE: Copying directory /path/to/codedx/analysis-files to /opt/codedx/

434
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

analysis-files...
VERBOSE: Copying directory /path/to/codedx/mltriage-files to /opt/codedx/
mltriage-files...
VERBOSE: Restarting Software Risk Manager...
Restarting srm-docker-codedx-tomcat-1 ... done
Restarting srm-docker-codedx-db-1 ... done
Done

Migration With an External Database

The following steps cover migrating data from a Software Risk Manager system installed with the native
installer to an existing Docker Compose deployment.
To migrate data from a Software Risk Manager system installed using the native installer:

1. Verify that your Software Risk Manager deployed with Docker Compose is running and using the
docker-compose-external-db.yml file. The external database details will need to be added to this file.
From the root of the project, the up command should look as follows:

docker-compose -f docker-compose-external-db.yml up

2. Verify that your Software Risk Manager deployed with the native installer is running.
3. Verify that the version numbers of both systems match.
4. Log on to your source Software Risk Manager server whose data you want to migrate.
5. Run mysqldump to create a backup file. You can run the following command to create a dump-srm.sql
file after specifying the parameters that work for your database.

mysqldump --host=127.0.0.1 --port=3306 --user=root -p codedx -r dump-sr

m.sql

Note: The above command uses a database named codedx. Older versions of Software Risk
Manager may use a database named bitnami_codedx.

6. You may encounter an issue running SRM if the database dump file makes use of DEFINER. Run the
following command with dump-srm.sql replaced with the path of your database dump file. This will
overwrite the existing database dump file with the definers removed.

(Get-Content "dump-srm.sql") -replace '\sDEFINER=`[^`]*`@`[^`]*`','' | Ou

t-File dump-srm.sql

435
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

7. Return to the system running Software Risk Manager with Docker Compose, change directory to this
repository (srm-docker folder), and run the migrate-data.ps1 script with the following commands. The
script will guide you through the rest of the procedure.

cd /path/to/srm-docker
pwsh ./admin/migrate-data.ps1 -externalDatabase

Note: The above command will use the default values for the script parameters
-tomcatContainerName (srm-docker-codedx-tomcat-1) and dbName (codedx). You can find your
Docker container names by running docker ps.

Your script output should look similar to the following:

pwsh ./admin/migrate-data.ps1 -externalDatabase

Enter the path to your Software Risk Manager AppData folder: /path/to/codedx
VERBOSE: Checking appdata path...
VERBOSE: Checking appdata/analysis-files path...
VERBOSE: Checking PATH prerequisites...
VERBOSE: Checking running containers...

Since your SRM deployment uses an external database (one that you maintain o
n your own
that is not installed or updated by the SRM deployment script), you must res
tore the dump-srm.sql file you
created in Step 5 of the migration instructions.

You can restore mysqldump files using a command that looks like this:

mysql -uroot -p srmdb < dump-srm.sql

Note: Replace 'root' and 'srmdb' as necessary.

VERBOSE: Deleting directories...

VERBOSE: Deleting directory /opt/codedx/analysis-files...
VERBOSE: Deleting directory /opt/codedx/keystore...

436
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

VERBOSE: Deleting directory /opt/codedx/mltriage-files...

VERBOSE: Copying directories...
VERBOSE: Copying directory /path/to/codedx/analysis-files to /opt/codedx/ana
lysis-files...
VERBOSE: Copying directory /path/to/codedx/mltriage-files to /opt/codedx/mlt
riage-files...
VERBOSE: Restarting Software Risk Manager...
Restarting srm-docker-codedx-tomcat-1 ... done
Done

Uninstall

You can remove Software Risk Manager and the related Docker volume(s) by running the following
command:

docker-compose -f /path/to/your-docker-compose-file down -v

Installation Using Kubernetes

Kubernetes deployment is required for high-availability and the ability to use Scan Farm and Tool
Orchestration.
For complete deployment instructions, see Deploying Software Risk Manager on Kubernetes.

Manual Installation

This section provides information on installing SRM manually. Note that while manual installation provides
expanded configuration options, it also requires a high level of technical knowledge and experience with
the third-party tools and software required to deploy SRM.

Stack
The supported stack for SRM is as follows:

• Java 11
• Apache Tomcat 8.5.x or 9.0.x
• MariaDB 10.6.x or MySQL 8.0.x

437
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Note: Other configurations are not guaranteed to work.

Prerequisites
Nothing specific beyond the stack should be required to install SRM on Linux or macOS.
On Windows, the VC15 runtime is required. For more information, see https://support.microsoft.com/en-us/
help/2999226/update-for-universal-c-runtime-in-windows.

Setup
Start by extracting the SRM zip file. The three files of interest are as follows:

• srm
• codedx.props
• logback.xml

AppData
SRM stores a variety of files, including configuration files, temporary files created during analyses, log files,
and copies of files uploaded by the user. The root location for these files is the SRM AppData directory.
You will need to create a directory to serve as the AppData directory (which will be referred to in these
instructions as SRM_APPDATA). Make sure that the user running Tomcat has read-and-write privileges to
SRM_APPDATA.
Move both codedx.props and logback.xml into SRM_APPDATA.
The user that Tomcat will be running as will need to have full access to the appdata folder. Since sensitive
data may be stored here as well, it is recommended that access to this folder be restricted via disk
permissions as well as access restrictions to the machine SRM will be running on.

Database
Create a new, empty database for SRM to use and create a user for SRM with SELECT, INSERT,
UPDATE, DELETE, CREATE, CREATE TEMPORARY TABLES, ALTER, REFERENCES, INDEX,
DROP, TRIGGER permissions on the database.
For example,

CREATE USER 'srm'@'%' IDENTIFIED BY 'enter-a-password-here';

CREATE DATABASE srm;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, CREATE TEMPORARY TABLES, ALTE
R, REFERENCES, INDEX, DROP, TRIGGER ON codedx.* to 'srm'@'%';

438
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

FLUSH PRIVILEGES;

Edit the codedx.props file to reflect your new database and the credentials required to connect to it. For
example,

swa.db.url = jdbc:mysql://localhost/srm
swa.db.user = srm_username
swa.db.password = srm_user_password

Required changes:

• Make sure sql_mode doesn't contain ONLY_FULL_GROUP_BY or PAD_CHAR_TO_FULL_LENGTH.

Newer versions of MySQL (as of v5.7) use a sql_mode that includes ONLY_FULL_GROUP_BY.
MariaDB includes neither setting by default, as of this writing. Make sure if using MySQL, sql_mode
doesn't include NO_AUTO_CREATE_USER as it's no longer supported in MySQL 8. To view the current
configuration of this, you may run the query select @@sql_mode. For example, the defaults for
MySQL 8 with the ONLY_FULL_GROUP_BY option removed would be
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,N
• optimizer_search_depth=0
• character_set_server=utf8mb4
• collation_server=utf8mb4_general_ci
• log_bin_trust_function_creators=1

Tomcat
Drop the srm.war file into Tomcat's webapps directory. (You can also deploy it via Tomcat's manager
interface if you prefer).
You also need to add a property to let the SRM app know the value of SRM_APPDATA. You will need to set
a value for the Java property codedx.appdata. You will also need to add
-Dcodedx.appdata=SRM_APPDATA to the list of CATALINA_OPTS values. (Where that's done is system-
dependent: see the Tomcat Documentation for details.) Alternatively, you can define a SRM_APPDATA
environment variable with this value, if you'd prefer that to configuring CATALINA_OPTS.
Additionally, you will need to ensure that the JVM will use UTF-8 as its file encoding. Doing so prevents
issues with Japanese user input like comments and manual results. Add -Dfile.encoding=UTF-8 to
the list of CATALINA_OPTS values.
Now when you start Tomcat, SRM will be able to access the codedx.props file.
Configuration
To make Tomcat stop reporting about cache issues, edit conf/context.xml and add <Resources
cachingAllowed="true" cacheMaxSize="128000" /> inside the <Context>.
It is also recommended to edit conf/server.xml and raise the value of Connector
connectionUploadTimeout, if applicable. This is set to 3600000 by default when using the SRM

439
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

installer. We also recommend setting disableUploadTimeout to false. In the same file,

connectionTimeout on the Connector is by default 20000 for an installation of SRM.
Further configuration may be performed per your deployment and requirements (such as configuring AJP
and placing an instance of Apache HTTPD in front of Tomcat or changing the logging configuration).

Starting SRM
For version 2023.12.5 or later, if SRM is being deployed behind a proxy that is using HTTPS, it is
recommended to set the prop auth.cookie.secure to true. This will allow the secure flag on the
session cookie to be set and passed along through HTTPS via the proxy.
Once everything is configured, start the database and Tomcat (make sure the database is running before
you start Tomcat). Open a web browser and point it at SRM (e.g., http://localhost/srm/). You will
be presented with an installation screen allowing you to set the super admin username and password and
initialize SRM.
You may need to add a codedx.internal-url setting to your codedx.props file. This should contain
a URL that SRM can access itself at, for example http://localhost/srm/ or https://localhost/
srm. This will depend on how exactly SRM is deployed.

Software Risk Manager Configuration

While the Software Risk Manager installer automates the configuration steps needed to match the system
and user selections made during the installation process, certain advanced options are configurable from
the Software Risk Manager configuration files. This section describes the configuration options for
Software Risk Manager in the event that changes to the default setup are required.

Understanding the AppData Directory

Software Risk Manager needs a place to store a variety of files, such as the analysis inputs it receives that
the source code that it uses to display in the Finding Details page, log files, and configuration files. These
files are placed in the Software Risk Manager appdata directory. This directory also contains important
information from the ongoing Software Risk Manager usage activity; therefore, it is recommended that this
directory be in a stable location that is periodically backed up.
The location of the appdata directory is set during installation. By default, the appdata directory is located
in the following locations:

• For Windows: C:\ProgramData\Software Risk Manager\codedx_appdata\

• For Linux (installed as root): /var/opt/srm/
• For Linux (installed as non-root: /home/srm_data/codedx_appdata/
• For Docker: /opt/codedx/

Enabling Intelligent Orchestration

Software Risk Manager provides an Intelligent Orchestration integration that allows the application of an IO
Pre-Scan policy to a Software Risk Manager analysis. (For more information on Intelligent Orchestration

440
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

and its use, see Intelligent Orchestration in the Software Risk Manager User Guide.)
Note: Intelligent Orchestration requires a separate IO license and may not be available in all
implementations.
To enable IO functionality, add the following configuration settings to the codedx.props file:

• io.enabled = true - sets whether or not to enable IO [default: false]

• io.url = io-url - sets the base URL for your IO server [example: https://io.codedx.com]
• io.api-key = io-token - sets the token used by Software Risk Manager to access the IO API
[example: ABCD...===]

(For more information on property settings and the codedx.props file, see Configuration Files.)

Configuration Files

Log Configuration File

Software Risk Manager uses Logback for logging. A sample logback.xml file is provided in the appdata
directory. For more information about the logging configuration, consult the Logback manual.

Automatic Log Deletion

For fresh installations of Software Risk Manager, the Logback configuration file will specify a default
retention period of seven days. To change the default, replace the value of maxHistory in the
logback.xml file with the desired number of days to retain a log file. Log files outside of this period will
be deleted.
Existing installations may achieve this same behavior by adding the following within the
<rollingPolicy> block in the logback.xml configuration file.

<!-- keep 7 days worth of history -->

<maxHistory>7</maxHistory>

After making any changes, it is recommended that you delete the log files—except codedx.log—from
the log-files directory to avoid unexpected behavior. Problems may occur because existing
installations will likely exceed the maximum number of log files Logback will delete at a time.
Note: With this configuration change, eligible log files are deleted with each rollover period (which is daily
for the default Software Risk Manager Logback configuration). If you also want log files to be deleted when
the Software Risk Manager server is started, add the code shown below just after maxHistory.

<cleanHistoryOnStart>true</cleanHistoryOnStart>

You must restart the Tomcat server after you've completed your revisions. This can be done by launching
the Software Risk Manager application's Manager Tool, clicking the Manage Servers tab, selecting Tomcat

441
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

server, and then clicking Restart.

Software Risk Manager Properties File

The most important configuration file is codedx.props, also referred to in this guide as the "props" file.
Located in the appdata directory, the props file configuration determines a variety of settings, including the
database connection information, the analysis behavior, and Active Directory integration.
The props file is formatted as a .properties file, using key-value pairs to set configuration fields.
When changing this file, remember to delete the comment designation (#) at the beginning of the line.
You must restart the Tomcat server after you've completed any revisions. This can be done by launching
the Manager Tool, clicking the Manage Servers tab, selecting Tomcat server, and then clicking Restart.

Database Connection Config

Software Risk Manager requires a MariaDB database for storage. The MariaDB database is automatically
installed and configured during installation. The following properties are used to configure Software Risk
Manager database connections and are set automatically during installation. Please do not modify these
settings unless there is a strong need to setup an alternate database for use with Software Risk Manager.
However, doing so might cause problems when installing Software Risk Manager upgrades.

• swa.db.url - The JDBC URL of the database Software Risk Manager will be communicating with
• swa.db.user - The username that will be used to access the database
• swa.db.password - The password that will be used to access the database

For instance, to configure Software Risk Manager to communicate with a MariaDB database running on
the same machine as the Software Risk Manager server with a username of "database_username" and
password of "database_password," use the following configuration:

swa.db.url = jdbc:mysql://localhost/codedx
swa.db.user = database_username
swa.db.password = database_password

Internet Access

Software Risk Manager uses internet access in the background for some activities, such as keeping tool
data up-to-date and periodically checking for a new Software Risk Manager release.
Software Risk Manager does not require internet access; however, to insure full functionality, internet
access is highly recommended.
To disable background internet access by Software Risk Manager, add codedx.offline-mode = true
in your properties file (codedx.props). The default is false. Note that this will not disable any internet
access that may occur as a result of user action or configuration settings, such as Tool Connector, Git, or
Issue Tracker configurations.

442
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

When internet access is enabled, Software Risk Manager will perform the following actions:

• Update notifications - Software Risk Manager will periodically check for newer versions and display an
update notification when one is available.
• Dependency-Check updates - Dependency-Check will periodically download updates from the National
Vulnerability Database, the Retire.js repository, or reach out to Maven Central while scanning Java
dependencies (this aids in the dependency identification process, to cut down on both false positive
and false negative results). If Software Risk Manager is in offline mode, this may lead to lower quality
results when running Dependency-Check as a bundled tool.
• Secure Code Warrior - Unless noted elsewhere, Software Risk Manager will reach out to any URLs
belonging to the securecodewarrior.com domain.

Dependency-Check External Access

The base paths below are external resources that Dependency-Check may attempt to access during
analyses or updates. If Software Risk Manager is not running in offline mode, ensure that all of the
following paths are accessible to allow normal operation:

• https://jeremylong.github.io/DependencyCheck/current.txt
• https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.json.gz
• https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-%d.json.gz (where %d is a year)
• https://static.nvd.nist.gov/feeds/xml/cpe/dictionary/official-cpe-dictionary_v2.3.xml.gz
• https://repository.sonatype.org/service/local/
• https://search.maven.org/solrsearch/select
• https://search.maven.org/remotecontent?filepath=
• https://repo1.maven.org/maven2/
• https://ossindex.sonatype.org
• https://registry.npmjs.org/-/npm/v1/security/audits
• https://raw.githubusercontent.com/Retirejs/retire.js/master/repository/jsrepository.json

Note: The first resource (https://jeremylong.github.io/DependencyCheck/current.txt) is not necessary for

proper operation; however, Dependency-Check will occasionally attempt to access it to check the latest
release version number.

Software Risk Manager External Access

To see the latest Software Risk Manager version: https://service.codedx.com/updates/
latestVersionData.json

Secure Code Warrior External Access

For Software Risk Manager Secure Code Warrior integration, Software Risk Manager will attempt to reach
out to a number of URLs that belong to the securecodewarrior.com domain. If Software Risk Manager
is not running in offline mode and Secure Code Warrior functionality is enabled, ensure that the domain

443
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

securecodewarrior.com (and all subdomains) are accessible to allow normal operation.

External URL

In most cases, Software Risk Manager can infer its own external URL based on the requests sent to it from
users. For example, you might access Software Risk Manager from https://localhost/codedx or
https://codedx.mycompany.com. This information is necessary for some subprocesses of Software
Risk Manager that need to communicate back to Software Risk Manager over HTTP, or to provide
accurate links back to Software Risk Manager when generating content—Issue Trackers, for example.
In some cases, the accurate "external URL" may not be available through inspection of user requests.
When this happens, the value must be provided from your codedx.props file via the codedx.external-
url property.

codedx.external-url = https://codedx.mycompany.com

Additionally, there are some cases where you may want internal services (running on the same machine as
Software Risk Manager) to access Software Risk Manager from a different URL compared to the external
URL. By default, the external URL will be used in this scenario (unless overridden by setting
codedx.internal-url):

codedx.internal-url = https://localhost:8443/codedx/

Active Directory/LDAP Configuration

Software Risk Manager allows you to create and deactivate new users that are only known to the Software
Risk Manager system. You may, however, want to let users use the same credentials as they do for your
organization. To facilitate this, you may provide an LDAP or Active Directory configuration in the properties
file (codedx.props). The available settings are as follows:

• auth.ldap.url = ldap://127.0.0.1:389/ – sets the LDAP URL to connect to; this setting is
required for LDAP usage.
• auth.ldap.systemUsername = sAMAccountName=admin,ou=users,dc=codedx,dc=com –
sets the system username (full account DN) that is used when connecting to the LDAP server for
authorization queries; this setting is not required if the LDAP server accepts anonymous queries.
• auth.ldap.systemPassword = secret – sets the password corresponding with the system
username (above) that is used when connecting to the LDAP server for authorization queries; this
setting is not required if the LDAP server accepts anonymous queries.
• auth.ldap.authenticationMechanism = simple – sets LDAP authentication mechanism for
authorization queries; accepted values are none (anonymous) and simple [default: none].
• auth.ldap.userSearchTemplate = sAMAccountName={0},ou=users,dc=codedx,dc=com –
controls the template to generate the user search query for authorization; more information can be
found here [default: <direct user input>].
• auth.ldap.useAsDnTemplate = false – whether to use the provided search template(s) as DN
templates instead [default: false].

444
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

• auth.ldap.useStartTLS = false – enable or disable the use of StartTLS after establishing an

LDAP connection [default: false].
• auth.ldap.legacyMode = false – enable or disable the legacy Code Dx LDAP implementation
[default: false].
• auth.ldap.user.groupAttribute = memberOf – set the name of the LDAP attribute on a user
that lists their groups [default: memberOf].
• auth.ldap.group.nameAttribute = cn – set the name of the LDAP attribute on a group that
indicates their readable name (leave blank for pass-through) [default: cn].
• auth.ldap.user.displayNameAttribute = cn – set the comma-separated list of LDAP
attributes names on a user indicating their display name; see the relevantsections below for syntax
[default: cn, userPrincipalName, sAMAccountName].
• auth.ldap.sync.autoUpdate = false – set whether or not to automatically schedule LDAP
group membership updates [default: false].
• auth.ldap.sync.refreshInterval = 5 minutes – set the refresh interval for automatic LDAP
group membership updates in readable text [default: "5 minutes"].
• auth.ldap.searchSubTree = true – sets whether or not to search sub-trees for users with the
provided userSearchTemplate(s) [default: true].

Note: LDAP property names were changed in Code Dx version 3.5.4. The previous names may still be
used.

You may be able to get by with only setting the auth.ldap.url property, depending on the complexity of
your LDAP setup. It may be necessary to use a fully-qualified username (e.g., [email protected]
rather than just john.doe) when adding the user to Software Risk Manager.
The systemUsername, systemPassword, and authenticationMechanism properties don't need to
be set for a secure LDAP configuration, due to the fact that they are not used during user authentication,
but for querying user information that will be used during their authentication. Read the section below for
more details.

User Search Template

The user DN is the fully qualified LDAP identifier for the user when logging in. In some LDAP systems, the
user DN may require an attribute that the actual user isn't aware of, such as an integer ID. Rather than
asking the user for this hidden attribute, the user provides a different unique identifier (such as their
account name) and Software Risk Manager will insert that into the given query to find a matching user with
that attribute. The text they enter as their username is used to replace the {0} part of the template.
In the example above (sAMAccountName={0},ou=users,dc=codedx,dc=com), when the user
attempts to log in, a query will be run on sAMAccountName=test,ou=users,dc=codedx,dc=com to
retrieve the user DN, which may give something like uid=12345,ou=users,dc=codedx,dc=com. This
user DN is then used to bind an LDAP connection using the discovered DN and the user's given password.
Note: In order to make this query, Software Risk Manager needs to be able to authenticate against the
LDAP server without the user's credentials. If the LDAP server supports anonymous queries, this won't be
an issue. If the LDAP server requires authentication, assign auth.ldap.authenticationMechanism
= simple and assign auth.ldap.systemUsername/auth.ldap.systemPassword to the credentials

445
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

to use when making these queries. The systemUsername should be the full, bindable DN for the user.
If no template is provided, the username entered by the user will be directly used, which may not map to
what your LDAP server is expecting. When specifying a user search template, the {0} placeholder must
be present. If it is missing, an error will be logged at Software Risk Manager startup, and LDAP
authentication will be disabled until the template is corrected. After correcting the LDAP authentication,
restart the Software Risk Manager Tomcat server.

Using as a DN Template
If performing a user search before binding is untenable in your environment, you can set Software Risk
Manager to treat the search templates as direct DN templates instead by assigning
auth.ldap.useAsDnTemplate = true. This means that each authentication performs only one bind,
using the resolved DN and the provided user password.
While this may provide slightly better performance, it is mostly useful when anonymous binds are
unsupported and there is no system user account available to perform a search.
Note: Enabling this option will disable LDAP connection pooling, so a new connection will be made and
bound for each authentication attempt. Also note that this option cannot be enabled when using multiple
templates.

Multiple Templates
Multiple search templates can be used by adding multiple, uniquely named properties, starting with
auth.ldap.userSearchTemplate. For example,

auth.ldap.userSearchTemplate-A = sAMAccountName={0},ou=users,dc=codedx,dc=co
m
auth.ldap.userSearchTemplate.B = cn={0},ou=customers,dc=codedx,dc=com

With the above properties, both of those search templates will be used to resolve a user DN when signing
in. The property names can be anything, as long as they start with auth.ldap.userSearchTemplate
and are unique. If auth.ldap.userSearchTemplate-A was used twice in the above example, the
second assignment would overwrite the first.
Note: Make sure that any LDAP user added to Software Risk Manager can be resolved by only one of the
registered search templates.

Sign-in with Multiple Names

When multiple search templates are provided, it is possible for the same LDAP user to sign in using
different names. Software Risk Manager resolves each LDAP user to their DN and stores that as their
identity, allowing the user to sign into the same Software Risk Manager account regardless of the name
used.
This DN resolution occurs when a user signs in and not when a user is manually registered through the
User Admin page. For their first sign-in, they must use the name that has been registered. This causes

446
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

their DN to be properly resolved and stored, allowing sign-in under different names.

User Merging
In rare cases, it is possible for two LDAP user entries to exist in Software Risk Manager that refer to the
same LDAP user. If two separate accounts resolve to the same DN during authentication, Software Risk
Manager will automatically merge the users. This merge creates a new user with the same name that is
being authenticated, reassigns all content from matching users to the new user, deletes those previous
users, and then authenticates with that new user. This invalidates any active sessions using either of the
two previous LDAP users.
Note: Any user merging will be accompanied by an entry in the Software Risk Manager server logs, as
well as the Visual Log, with appropriate details.

Display Names
The LDAP attribute used for display names can be set with
auth.ldap.user.displayNameAttribute, which is a comma-separated list of attribute names. Each
attribute is checked in order, and the first received value is used. If unassigned, Software Risk Manager
will attempt to use their CN, UPN, and SAN, in that order.
Display names are automatically updated when a user signs in. Changes to the
displayNameAttribute property won't affect users until they sign in again.
Single-value LDAP attributes will be used as-is, if available. Multi-value attributes will have their first entry
selected by default. You can choose a specific index in the list, if needed, by using the syntax
myAttribute{n}, where n is the 0-based index in the attribute list. For example, you can select the
second value in a list while falling back to another attribute with the following:

auth.ldap.user.displayNameAttribute = myAttribute{1}, someOtherAttribute

You could also prioritize a second value while falling back to the first with:

auth.ldap.user.displayNameAttribute = myAttribute{1}, myAttribute{0}

Note: myAttribute{0} and myAttribute are equivalent; they both select the first value available from
the attribute.

LDAP Group Mapping

LDAP groups for your users can be mapped to Software Risk Manager groups within the application. This
requires connection to an LDAP server that provides a user attribute listing its groups, such as Active
Directory and its memberOf attribute.
This group mapping requires a valid groupAttribute and nameAttribute to be assigned in your
codedx.props file. The defaults are suitable for use with an Active Directory server and can be left

447
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

unassigned if using Active Directory.

The auth.ldap.user.groupAttribute is the name of the attribute on your user objects that lists the
groups that the user is a member of. This is typically a multi-value attribute containing the full DN paths for
a user's groups.
The auth.ldap.group.nameAttribute is the name of the attribute on your group objects that
determine how you refer to those groups in Software Risk Manager. When defining what a Software Risk
Manager group will map to, you will use the values provided by that attribute. This is used to pull a
readable name from the groupAttribute of any authenticated users.

SAML Configuration

Software Risk Manager can also be configured to authenticate against a SAML 2.0 IdP (Identity Provider).
This can be done by using the settings below.

Note: SAML authentication isn’t currently supported for Software Risk Manager plugins.

• auth.saml2.identityProviderMetadataPath – [required] Sets the file path to the XML

metadata for your SAML IdP (file must exist on the Software Risk Manager host).
• auth.saml2.keystorePath [default: internal Software Risk Manager path] – Sets the signing key
for SAML requests by Software Risk Manager; must be JKS format with the appropriate cert, private
key, and an assigned password for both the JKS key store and private key; will be auto-generated at an
internal Software Risk Manager location if unassigned.
• auth.saml2.keystorePassword – [required] Sets the password used to open the assigned JKS
file.
• auth.saml2.privateKeyPassword – [required] Sets the password to use with the private key
stored in the assigned JKS file.
• auth.saml2.uniqueNameAttribute [default: user's Name Id] – Sets the specific attribute to use as
the unique username ID; the value of this attribute is used as the user's login ID and display name.
• auth.saml2.namePolicyFormat default: from IdP XML – Sets the accepted/required format of the
Name Id.
• auth.saml2.entityId default: https://codedx.com – Sets the entity ID used to identify Software Risk
Manager as a service provider when registering with your IdP.
• auth.saml2.responseBindingType [default:
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST] – Sets the Assertion Consumer Service
(ACS) binding type for Software Risk Manager.
• auth.saml2.authnRequestBindingType [default: from IdP XML] – Sets the binding type to use
when Software Risk Manager submits Authn requests to your IdP (must be supported by your IdP's
SSO service endpoint).
• auth.saml2.maximumAuthenticationLifetime [default: 3600] – Sets the maximum allowed age
(in seconds) of the AuthnInstant specified in an Authn Response from the IdP. This is an additional
(but not entirely necessary) validation step performed by Software Risk Manager. If rolling session
lifetimes are in place from your IdP, this may be disabled by setting to -1 (which sets the max lifetime to
10 years).
• auth.saml2.maxSkewSeconds [default: 120] – Sets the maximum allowable difference in UTC time
between the Software Risk Manager server and an IdP server (loosens the window of

448
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

maximumAuthenticationLifetime).
• auth.saml2.passive [default: false] – Sets whether or not to use passive authentication against
your IdP.
• auth.saml2.forceAuth [default: false] – Sets whether or not to force re-authentication with your
IdP when the user attempts to start a new Software Risk Manager session (this re-authentication may
start a new session and invalidate existing SAML sessions with other applications).
• auth.saml2.requireSignedAssertions [default: false] – Sets whether or not Software Risk
Manager should require signed assertions from your IdP (regardless of whether the message as a
whole was signed).
• auth.saml2.requireSignedResponses [default: false] – Sets whether or not Software Risk
Manager should require signatures on all responses from your IdP.
• auth.saml2.signAuthenticationRequests [default: false] – Sets whether or not Software Risk
Manager should sign authentication requests to your IdP.
• auth.saml2.useNameQualifier [default: false] – Sets whether or not Software Risk Manager
should include a name qualifier in Authn requests to your IdP.
• auth.autoExternalRedirect [default: true] – Sets whether or not to automatically redirect
unauthenticated users to your IdP login portal.
• ui.auth.samlLabel [default: SAML] – Sets the label for SAML-related operations within the
Software Risk Manager interface; this will be displayed when signing in to Software Risk Manager or
when creating new user.

Supported Profiles
Software Risk Manager adheres only to the Web SSO Profile. (Software Risk Manager also does not make
use of RelayState.) Other profiles, including Single Logout (SLO), are unsupported.

Basic Configuration
Upon successful configuration and after navigating to the Software Risk Manager Login page, your
codedx.log file should contain the message "Successfully configured SAML authentication." Otherwise,
it will contain "SAML authentication was either incomplete or missing, skipping." A minimal configuration
looks like the following:

auth.saml2.identityProviderMetadataPath = C:/idp-metadata.xml
auth.saml2.keystorePassword = jkspassword
auth.saml2.privateKeyPassword = pkpassword

The IdP XML should have a root element of <*:EntitiesDescriptor>. with

<*:EntityDescriptor> elements inside. The recommended location for this file is in the Software Risk
Manager appdata folder, but this is not in a requirement. Ensure that Software Risk Manager has the
necessary permissions to read the XML file.
The keystore is used by Software Risk Manager to sign requests to your IdP. This keystore will be created
automatically unless keystorePath is assigned and a file exists at the assigned path. The passwords for
the keystore and its private key must be set manually through the keystorePassword and

449
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

privateKeyPassword properties. The assigned passwords will be used to create the keystore if
necessary. The default path for the keystore is in Software Risk Manager appdata directory, at
.../codedx_appdata/keystore/codedx-saml.jks. If a custom keystore is provided, this folder is
the recommended location. Ensure that Software Risk Manager has the necessary permissions to read the
keystore file.
Software Risk Manager has no inherent requirements for the IdP it authenticates against. Requests from
Software Risk Manager can be configured as necessary using the properties listed above to meet the
needs of your IdP.
Navigating to Software Risk Manager will redirect you to your IdP Login Portal, which you may sign into but
will not provide access to Software Risk Manager. You must first add your SAML account as a user
recognized by Software Risk Manager. See the Software Risk Manager User Guide for more information.
By default, Software Risk Manager will redirect you to your IdP, but you can sign in using the Software Risk
Manager Login page by navigating to /login?local. Here you can enter the default Software Risk
Manager admin and password to sign in and add yourself and others as SAML-authenticated users.
If you get a generic error page after signing in with SAML, you may need to explicitly assign the Software
Risk Manager base path. This should match what you have registered with your IdP. See the section on
Multiple Hosts below for more information.

SP Metadata
The full XML Metadata for Software Risk Manager as an SP can be downloaded from the Users page if
SAML has been configured (see figure below). Notable details are provided below.

The Software Risk Manager Assertion Consumer Service (ACS) endpoint is at /login/callback/saml,
relative to your Software Risk Manager URL. For example, if hosting at https://localhost/srm, the
ACS will be https://localhost/srm/login/callback/saml.

450
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

The metadata XML will list the ACS binding type as HTTP-POST, regardless of the binding type set in
codedx.props. This can be ignored. Software Risk Manager will use the binding type specified in
codedx.props. You can change the binding type in that XML if necessary.

Callback URL, Proxies, and Multiple Hosts

Software Risk Manager can be accessed through a variety of hosts (such as machine name, FQDN, IP
address, reverse proxy), but only one will be recognized by Software Risk Manager as its ACS. The
Software Risk Manager ACS is built dynamically when the first request is made, and it is based on the first
URL requested from Software Risk Manager. If you access Software Risk Manager through
https://192.168.1.10/srm, the ACS URL will be at https://192.168.1.10/srm/login/
callback/saml and Software Risk Manager will only respond to SAML requests to that endpoint. SP
metadata will also be based on this URL.
In this case, SAML authentication will fail unless your IdP has the Software Risk Manager ACS at the
https://192.168.1.10/... endpoint. The downloaded SP metadata will have your SAML IdP redirect
using the Software Risk Manager IP, when you may want it to point to a reverse proxy instead.
You can assign the auth.hostBasePath property in your codedx.props file to force a consistent ACS
URL. This affects the endpoint that Software Risk Manager will listen to, along with the SP metadata that it
generates. If Software Risk Manager is accessible at https://myhost/srm, you can add the following:

auth.hostBasePath = https://myhost/srm

This will force a consistent ACS URL to https://myhost/srm. (Note: This only affects authentication; it
will not change the base path of Software Risk Manager itself.)

Single Log-Out and Ensuring Active Sessions

Software Risk Manager currently does not support any of the capabilities specified in the SAML Single
Logout (SLO) Profile.
If a user signs out from their SAML session, this logout will not automatically propagate to Software Risk
Manager.
To prevent the use of expired SAML sessions, we strongly recommend configuring Session Lifetimes
within Software Risk Manager to ensure the SAML session is validated frequently.

Automatic SAML Authentication

Once SAML is configured within Software Risk Manager, all login requests will be redirected to your IdP
authentication portal. Authenticated users will be redirected back to Software Risk Manager, where they
can view the Projects page if they are registered with Software Risk Manager. Otherwise, they will be
redirected to the Software Risk Manager Login page, where they can log in as a local user or retry
authentication with your IdP. Software Risk Manager does not perform any single sign-out; signing in with a
different SAML user will require signing out through your IdP portal and re-authenticating with the new user
information.

451
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

You can disable the automatic redirect to your IdP by setting auth.autoExternalRedirect = false
in your codedx.props.

Multiple Software Risk Manager Deployments with the

Same IdP
Authenticating multiple Software Risk Manager instances against the same IdP requires setting a unique
Service Provider Entity ID for each deployment. Assign the auth.saml.entityId property to different
values for each deployment, and register each new Entity ID with your IdP using the appropriate ACS for
the associated deployment.
For example, consider the following: Two Software Risk Manager deployments are hosted at
https://foo.com/srm and https://bar.com/srm. Modify auth.saml.entityId for both; in this
case they are assigned to https://codedx-foo.com and https://codedx-bar.com, respectively.
Software Risk Manager places no restrictions on Entity IDs; you can assign them as appropriate for your
case.
Restart both Software Risk Manager deployments and register them with your IdP as follows:

• Register entity https://codedx-foo.com with its ACS https://foo.com/srm/login/

callback/saml
• Register entity https://codedx-bar.com with its ACS https://bar.com/srm/login/
callback/saml

Both deployments will authenticate against your SAML provider. Note that users registered with one
Software Risk Manager deployment will not be registered with another, even if they authenticate against
the same IdP. Accessing both deployments with SAML user "John Doe" will require registering them with
each Software Risk Manager deployment individually.
While multiple Software Risk Manager installations are supported, it is discouraged to run them on the
same machine. This will likely lead to resource contention, resulting in performance degradation in those
installations.

Forcing Local Sign-in

Software Risk Manager does not validate that the configured IdP is available before attempting to
authenticate. If your SAML IdP becomes unavailable or you need to sign in through a local account, there
are two options:

1. Set auth.autoExternalRedirect = false in your codedx.props. Unauthenticated users will

be redirected to the Software Risk Manager Login page instead of your IdP portal, where they can sign
in with a local account or attempt to sign in through your IdP portal through a link below the sign in
form.
2. Manually navigate to /login?local, relative to your Software Risk Manager hosting path. This will
force the Software Risk Manager Login page to display regardless of the value of
auth.autoExternalRedirect.

452
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Note: You may not be able to sign in as a SAML user while your IdP is offline, even if you had been
previously authenticated.

IdP-Specific SAML Instructions

Identity Providers with known special considerations are discussed below. Presence (or non-presence) of
a particular IdP does not reflect which IdPs are "supported" or "preferred"; the list of IdPs and known
issues may not be comprehensive.

Azure AD
Software Risk Manager can use Azure for SAML authentication by registering Software Risk Manager as
an "Enterprise application." To do this, click "Create your own application," enter a name, and then select
"Non-gallery" from the available options.
Once created, open the newly created application, select "Single sign-on," and then select "SAML."
Only two properties must be specified: the app's Identifier and Reply URL. The Identifier should be
https://codedx.com, unless auth.saml2.entityId was changed to a different value in the
properties file. The Reply URL should be the Software Risk Manager ACS URL as described in the SP
Metadata section.
Note: Software Risk Manager does not support Relay State or Single Logout. Sign-on URL may be blank
or set to the /srm/login page.
After editing "Basic SAML Configuration" as described, save your changes and confirm that the Identifier
field was set with the expected value.
There are two locations to confirm: Within the "Single sign-on" page for your Enterprise registration, and
the "Expose an API" page in the associated App registration.
The Identifier from the "Enterprise registration -> Single sign-on" page should match the "Application ID
URI" from the "App registration -> Expose an API" page; both should match the entity ID for Software Risk
Manager.

Important Properties Settings

Configuration of Software Risk Manager for Azure AD only requires the basic mandatory settings:
auth.saml2.identityProviderMetadataPath, auth.saml2.keystorePassword, and
auth.saml2.privateKeyPassword.
The maximumAuthenticationLifetime must also be configured properly for a reliable integration. The
section below discusses this in more detail.

Session Lifetime Considerations

Integrations with Azure AD must pay attention to the maximum lifetime of a session. At the time of writing,

453
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Azure AD's default lifetime is a "rolling window" of 90 days. Typically the 90 days would be converted to
seconds and used as the value for the Software Risk Manager property
auth.saml2.maximumAuthenticationLifetime.
Synchronizing this setting between Software Risk Manager and Azure AD (or any IdP) is important: If
Software Risk Manager receives an authentication response containing a session older than the maximum
allowed lifetime, the response will be rejected with an error message.
If a policy with a rolling window is applied, there is effectively no single "maximum" age Software Risk
Manager can expect. In this case, we recommend disabling the sliding window within Azure, or disabling
the Software Risk Manager SAML session lifetime limit by setting
auth.saml2.maximumAuthenticationLifetime to -1.
The original 90-day value (7776000 seconds) may be used regardless of the rolling window. In this case,
users attempting to authenticate with Software Risk Manager must manually start a new session with their
IdP once their session exceeds that age.
Behavior in Azure AD may be viewed or customized with the "Conditional Access" policies available.

SAML Group Mapping

Software Risk Manager can detect SAML group information during authentication, which can then be used
to auto-create SAML users and enable mapping between SAML and SRM groups to automatically add/
remove users from SRM groups.
The auth.saml2.groupMappingMethod option in codedx.props specifies which method to use. For
more information, see the Single SAML Attribute and Multiple SAML Attributes sections below.
Software Risk Manager can read group information for a SAML user through either of the following
methods:

• Method 1: A single SAML attribute containing a list of user groups (string-list)

• Method 2: Multiple SAML attributes, each indicating membership of one user group (multi-attr)

Selecting the appropriate mapping method will depend on your SAML IdP and how it is configured to
provide user group information. (These methods cannot be used together at the same time.)

Note: SRM does not support the Assertion Query/Request SAML profile and can only access user SAML
groups during authentication. Enabling Session Lifetimes is recommended to ensure users are regularly
signed back in and updated (see Session Expiration).

Method 1: Single SAML Attribute

For single SAML attribute mapping, add the following to the properties file:
auth.saml2.groupMappingMethod = string-list. This method also requires setting the
auth.saml2.groupAttribute property to the name of the SAML attribute containing the list of user
groups (this attribute name is case-sensitive).
This attribute will be interpreted as a comma-separated string, where each entry is a group that the user is

454
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

a member of.
This method supports both single-value and multi-value attributes. For multi-value attributes, each value is
interpreted as an additional comma-separated list and is combined with the others for the final list of user
groups.

Method 2: Multiple SAML Attributes

For multiple SAML attribute mapping, add the following to the properties file:
auth.saml2.groupMappingMethod = multi-attr. This method also requires adding at least one
prop, beginning with auth.saml2.groupAttributePattern. (The prop groupAttributePattern
acts as a template for extracting groups from a user's list of attributes.)
The value of groupAttributePattern should match the format of the relevant attribute names and use
{group} as a placeholder for the part containing the group name. For example, given an attribute named
is-secops-group, you would use the pattern is-{group}-group.
You can handle multiple patterns by adding additional groupAttributePattern props, such as in the
following example:

auth.saml2.groupAttributePattern = is-{group}-group
auth.saml2.groupAttributePattern-other = member-of-{group}

Note: A pattern value must contain exactly one occurrence of the text {group}.)

All patterns described by props starting with auth.saml2.groupAttributePattern will be used

together to detect the list of user groups. (This is unaffected by whether one pattern detects a match or all
patterns have a match—if any pattern matches an attribute name, it will be recognized as a group name,
regardless of whether other patterns match that attribute.)
With groupMappingMethod = multi-attr and groupAttributePattern* set, a user will be
considered a member of any group that matches the specified pattern.
You can also have Software Risk Manager check the value of the attribute using
auth.saml2.membershipAttributeValues and/or
auth.saml2.nonMembershipGroupAttributeValues. These options can be set to comma-
separated lists of values that are used to determine membership/non-membership:

• If membershipAttributeValues is set, a user will only be considered a member of a group if the

attribute contains one of the values assigned to the prop. Any other value will be interpreted as “non-
membership.”
• If nonMembershipAttributeValues is set, a user will be considered as not a member of the group
if the attribute contains one of the assigned values. If not set, or if the attribute value does not match,
group membership is determined by membershipAttributeValues behavior.

455
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Account Lockout

Software Risk Manager will automatically lock user accounts that are attempting to log in too many times.
When a user's account is locked, they can no longer log in until the account is unlocked. An account will
either unlock after the set lockout duration has elapsed, the password is reset, or when it was manually
unlocked by an admin. Admins may view locked accounts and unlock them on the users page.
Note that SRM only locks local user accounts. Other authentication schemes such as LDAP, SSO, etc., are
not subject to these rules and may have rules of their own.
All of these parameters for lockout may be customized via the following props:

• auth.lockout.enabled – [default: true] Determines if the account lockout feature is enabled or not.
Note that setting this to `false` will not unlock already locked accounts
• auth.lockout.timespan – [default: 15 minutes] The time period in which the log in attempts must
occur
• auth.lockout.attempts – [default: 5] The number of failed attempts that must occur before the
account is locked
• auth.lockout.duration – [default: 1 hour] How long the account will be locked for. After the
lockout duration, a user can attempt to log in again. This value may be set to 0 if an indefinite lockout is
desired

Password Policy

Software Risk Manager can be configured to have new/edited local user passwords meet certain
requirements.
The defaults for SRM’s password requirements are listed below; however, requirements can be specified
by setting the appropriate properties:

• local-password-policy.minimum-length = 12 - Require a minimum length [default: 12].

• local-password-policy.maximum-length = 1048576 - Require a maximum length [default:
1048576].
• local-password-policy.contains-lowercase = false - Require a lowercase character
[default: true].
• local-password-policy.contains-uppercase = false - Require an uppercase character
[default: true].
• local-password-policy.contains-number = false - Require a number [default: true].
• local-password-policy.contains-special-character = false - Require a special
character (e.g. $ ! # %) [default: true].
• local-password-policy.common-check.enabled = true - Require passwords to be distinct
from an internal set of known compromised passwords [default: true].
• local-password-policy.unique-password-check.enabled = true - Require passwords to
be distinct from the last n previously used passwords, where n is configurable [default: true].
• local-password-policy.unique-password-check.num-to-check = 10 - The last n
previous passwords to prohibit a user from setting as their password [default: 10].
• local-password-policy.reset-on-first-login = true - Require that users set a new
password when logging in for the first time [default: true].
• local-password-policy.reset-after-admin-sets-password = true - Require that users

456
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

set a new password when an admin resets their password [default: true].
• local-password-policy.max-password-age = 12 months - Require that users set a new
password after a set amount of time since it was last reset. This can be disabled by setting a value of 0
[default: 12 months].

Header-Based Authentication

Software Risk Manager allows you to authenticate users via a request header. Requests to the Software
Risk Manager server which provide the configured header with a username as its value will be treated as
"logged in" as that user. You can optionally restrict the IP addresses from which such requests can
originate. For example, if you put Software Risk Manager behind a proxy server that manages its own
authentication and adds the header only to authenticated requests, you would specify the proxy server's IP
address as the only "allowed" IP address.
The name of the request header and the set of allowed IP addresses are configured by the following keys
in the codedx.props file:

codedx.header-authentication.header = My-Magic-Authentication-Header
codedx.header-authentication.allowed-ips = 172.1.1.1, 127.0.0.1,
0:0:0:0:0:0:0:1

There is no default value for header key. If omitted, header-based authentication will be disabled. If the
allowed-ips key is not specified, all IP addresses will be considered "allowed." This will also cause a
warning in your log, as it is not recommended to configure a header without an allowed-ips whitelist.
Once configured, header-based authentication and username/password logins will be mutually-exclusive;
you cannot log in via header while already logged in via username/password, and vice versa. There is no
"log out" functionality for a header-based session. Instead, you need to stop sending the header with your
requests.
Header-based authentication may be used to log in as any enabled user that has been added to Software
Risk Manager. This includes the super-admin user, all local users, and all LDAP users. Because of this, it
is highly recommended to provide an allowed-ips whitelist and hide the Software Risk Manager server
behind a proxy that can manage the header.

External User Auto-Registration

Software Risk Manager supports auto-registration of users that sign in through external methods such as
LDAP and SAML. This can include automatic creation, enabling, and disabling of users based on their
properties. This is particularly useful when managing an installation using third-party authentication, where
there may be many users in your organization that need to be maintained.

Note: User auto-registration respects the user limit of your license; if a new user attempts to sign in
without any seats available, they will receive an error message regarding license limitations.

457
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Auto-Registration with LDAP

Auto-registration can be configured in your codedx.props file with the following settings:

• auth.auto-create.ldap.enabled – set whether to auto-create LDAP users that don't exist yet in
Software Risk Manager [default: false]. (This setting was previously exposed as auth.auto-
create.enabled which will be deprecated in an upcoming release.)
• auth.auto-create.ldap.group-names = foo, bar – a comma-separated list of group names,
where an LDAP user must be a member of at least one of those groups to allow auto-creation [default:
none].
• auth.auto-create.ldap.auto-toggle-enabled – set whether to automatically enable/disable
LDAP registered users based on their membership in the provided LDAP group names (no effect if
group-names is unassigned or empty) [default: false].

When using auto-registration with LDAP, we recommend using both the group-names and auto-
toggle-enabled options. Without group-names, any LDAP user can sign in to Software Risk Manager.
Without auto-toggle-enabled, a user leaving one of those required groups would still be allowed to
sign in to Software Risk Manager.
Note: LDAP group membership checks are only available for LDAP providers that maintain an attribute on
users listing their memberships (e.g., Active Directory and its memberOf attribute).
Auto-registration with LDAP requires a valid LDAP configuration in your codedx.props file, and Software
Risk Manager must have permission to read the necessary LDAP objects and attributes to check for group
membership. This depends on your LDAP server configuration, but typically requires that you've assigned
a systemUser and systemPassword and set authenticationMechanism = simple in your
codedx.props file.
Note: Automatic enable/disable of users occurs when logging in. Changing the user's LDAP group
membership will not sign the user out or disable them. If necessary, you can disable or delete the user
manually. Configuring session durations in Software Risk Manager may also be useful.
Also note that LDAP group names in the group-names property does not need to match any LDAP group
mappings in your Software Risk Manager user groups, though there may be some overlap.

Auto-Registration with SAML

Auto-registration can be configured in your codedx.props file with the following settings:

• auth.auto-create.saml.enabled – set whether or not to automatically create SRM users when a

SAML user signs in (optionally gated by group-names) [default: false].
• auth.auto-create.saml.group-names – a comma-separated list of group names used as a
requirement on auto-create and auto-toggle behavior [default: none].
• auth.auto-create.saml.auto-toggle-enabled – set whether or not to automatically enable/
disable SRM SAML users depending on their group membership (requires group-names be set)
[default: false].

When using auto-registration with SAML, using both the group-names and auto-toggle-enabled

458
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

options is recommended.
Auto-registration with SAML requires a valid SAML and SAML Groups configuration in your codedx.props
file.

Cookie Config

For SRM 2023.12.5 and later, the prop auth.cookie.secure is available and gives control for setting
the secure flag on the session cookie used by SRM. Native HTTP installs will have this prop set to false
and HTTPS installs will have this set to true. If not using a native install, and HTTPS is being used
between the client and SRM, this attribute will need to be manually set to true in the props file.

• auth.cookie.secure - [default: false] When SRM is communicating over HTTPS, the secure flag on
the session cookie will always be set regardless of the value of this prop. When SRM is communicating
over HTTP, the value of this prop controls if the session cookie has this flag set. Where true means
the secure flag is set.

Session Expiration

You can set user sessions to expire after a period of inactivity using the settings below:

• session.lifetime - sets the duration of inactivity required before automatically signing out a user; if
set to 0, sessions will never expire [default: 20 minutes]
• session.timeout-notice - sets the point at which the user will be notified when their session will
expire [default: 2 minutes]

Both of these properties use a readable duration format, that is, 1 hour, 1 hour and 30 minutes, 3
days, and so on.
Enabling session expiration requires assignment of session.lifetime, but session.timeout-
notice is optional. If left unassigned, the timeout notice will be the shortest of either two minutes or 25%
of the session expiration period.
If session expiration is enabled, the user's session will be closed if it either times out or if the user closes
their browser.
Note: If combining session expiration with SAML authentication, make sure to set
auth.saml2.forceAuth = true so that the user always has to re-authenticate with your IdP.

Sessions can also be invalidated if SRM is configured to only allow one user session at a time with the
following setting:

459
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

• srm.limit-sessions.enabled - [default: false] Controls if user sessions should be limited to one at

a time

EULA Acceptance

Normally after the initial installation of Software Risk Manager, the end-user license agreement (EULA) will
be presented to the first admin user to log in. You can configure Software Risk Manager to skip this step by
accepting the EULA via the props file:

codedx.eula-accepted = true

Data Retention Configuration

To help manage data retention, Software Risk Manager offers the following settings to enable the purging
of old data:

• findings.purge-after-days [default: unspecified] - if specified, sets the number of days to retain

Findings marked as Gone. For example, findings.purge-after-days = 90.
• results.purge-after-days [default: unspecified] - if specified, sets the number of days to retain
archived Results. For example, results.purge-after-days = 7.
• visual-log.purge-after-days [default: 30] - if specified, sets the number of days to retain Visual
Log entries. For example, visual-log.purge-after-days = 45. Setting the value to -1 will cause
all visual log entries to be retained.
• analysis.logs.cleanup-mode [default: expired] - sets what strategy is used to clean up analysis
logs. Valid values are:
• expired - delete analysis logs older than analysis.logs.days-to-keep.
• archived - delete logs for analyses where all of its inputs are archived.
• expired-or-archived - delete logs for analyses that are either older than
analysis.logs.days-to-keep, or have all of their inputs archived.
• expired-and-archived - delete logs for analyses that are both older than
analysis.logs.days-to-keep, and have all of their inputs archived.
• disabled - analysis logs are not deleted.
• analysis.logs.days-to-keep [default: 7] - sets the number of days to retain analysis logs if the
analysis.logs.cleanup-mode is set to expired, expired-or-archived, or expired-and-
archived.
• analysis.logs.cleanup-time [default: 00:00] - sets the time of day that analysis log clean up is
ran. A value for this property should be a 24-hour time in the form HH:MM. For example 01:00 for 1 in
the morning, or 13:00 for 1 in the afternoon.

Findings
When enabled, findings that are marked as Gone and have not been modified for more than the specified

460
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

number of days will be removed. For a finding to be eligible for removal, it must be marked as Gone and
not have been modified recently on all Branches that it is present on. If the finding has been modified
recently or has a status other than Gone on any branch, then the finding will be kept on all branches.

Results
When enabled, results coming from Analysis Inputs that have been archived and are older than the
specified number of days will be removed. However, results that are associated with findings that are
marked as Gone will not be removed. This is done to prevent a scenario where a Gone finding has no
associated results (since all results associated with a Gone finding will be archived). Any findings removed
per the data retention configuration above do not count toward this condition. Results will be removed on
any branch where these conditions are met, regardless of their status in other branches.

Visual Log
When enabled, Visual Log entries that are older than the specified number of days will be removed.

Git Related Configuration

Software Risk Manager allows you to configure each project to automatically use source from a git
repository as input for each analysis. When configuring a connection to a git repository, Software Risk
Manager will, by default, disallow the usage of “local” URLs (i.e., URLs that point to a file in the Software
Risk Manager file system). This is enforced as a security measure to prevent system information exposure
via the validation user interface. Although it is strongly recommended that this setting be left disabled, in
the exceptional cases where it is necessary to use local git repositories, set the git.config.allow-
local-urls property to true.
When configuring a git repository connection, Software Risk Manager uses a request timeout of 60
seconds by default. This timeout can be changed by setting a value for the git.config.timeout
property. For example, a value of 2 minutes changes the timeout to 2 minutes.

Job Configuration

Software Risk Manager performs most long-running tasks, including background cleanup tasks, on a job
system. Controls are in place to limit the number of such tasks running concurrently to ensure the system
isn't overloaded. The resource limits listed below may be adjusted. Higher numbers translate to more
available resources of that type. The minimum value allowed is 1000, and the default is 2000. Values for
this setting are unitless; they are relative measures of the power of your Software Risk Manager server.
Certain jobs are more CPU-intensive, while others are more database-intensive. Each running job uses a
certain amount of the "limit," and this is the mechanism for limiting job concurrency.
These values should be adjusted in relation to the default value. For example, if you believe your server is
twice as powerful as an average server, set these settings to 4000 (double the default) to increase the
number of concurrent jobs that may be run.

• swa.jobs.cpu-limit determines the maximum available CPU

461
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

• swa.jobs.memory-limit determines the maximum available memory

• swa.jobs.database-limit determines the maximum available database I/O
• swa.jobs.disk-limit determines the maximum available disk I/O

In addition, certain jobs (e.g., generating reports for a project) may produce outputs. The
swa.jobs.expiration (default: 60) setting specifies how long the job results will be available (in
minutes).

Analysis Behavior

Various settings allow you to affect Software Risk Manager behavior regarding the analyses it conducts.
Changing any of the analysis behavior properties can be done at any time after the initial installation;
however, you will still need to restart the Tomcat server to reload the properties.

• analysis.concurrent-analysis-limit (default: 2) - the maximum number of analyses to run

concurrently. Note that this does not override the Job Configuration settings, but merely sets another
limit.
• storage.keep-raw-inputs (default: true) - when this setting is true, Software Risk Manager will
keep copies of all files uploaded for analysis. While these inputs are not required by Software Risk
Manager after the analysis is complete, keeping them for archival purposes will allow them to be
downloaded from the Show Inputs list. If storage space is an issue, setting this to false will prevent
Software Risk Manager from storing the raw inputs.
• storage.keep-archived-inputs (default: false) - when this setting is true, Software Risk
Manager will keep all uploaded files, whether they are archived or not. Leaving this setting false will
cause Software Risk Manager to delete stored copies of data upon archival. Note that this setting is
dependent on the value of storage.keep-raw-inputs, which must also be true in order to keep
the archived data.
• swa.tools.keep-all-logs (default: false) - this setting determines whether to keep all the log
files for the tools that Software Risk Manager runs. If false, only the logs from failures are kept.
• swa.upload.maxfilesize (default: 2048) - this setting controls the maximum file upload size
allowed (in megabytes) for a single file.
• swa.upload.maxuploadsize (default: 2048) - this setting controls the maximum size of all
uploaded files (in megabytes) for a single analysis.
• codedx.analysis.hybrid-enabled-by-default (default: false) - this setting determines the
default value for the "Enable hybrid analysis" setting in Analysis Config. Since hybrid analysis requires
some relatively time-consuming steps, this setting is false by default.
• codedx.analysis.auto-archive-enabled-by-default (default: true) - this setting
determines the default value for the "Archive findings" setting in Analysis Config. Most projects will only
upload a scan from a tool if it represents a new state of the project, but an organization may want to be
able to upload many tool result files in sequence without having them interfere with each other. Such
organizations should set this setting to false.
• codedx.analysis.auto-archive.excluded-tools (default: none) - this setting allows excluding
outputs from certain tools from the auto archival process. This setting is a comma-separated list of the
names of the tools to exempt from auto archival.
• ingestion.skip-code-metrics (default: false) - if set to true, code metrics will not be gathered
during analysis.
• finding.reopen-gone (default: true) - this setting determines the default value for the "Allow gone

462
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

findings to be reopened" setting in Analysis Config.

• finding.reopen-resolved (default: false) - this setting determines the default value for the
"Reopen resolved findings when updated" setting in Analysis Config.
• storage.keep-failed-analysis-inputs (default: false) - this setting determines whether to
keep files associated with failed analyses.
• analysis-prep.idle-lifetime (default: 30 minutes) - this setting controls how long an analysis
prep must be inactive before it expires and its prep id becomes invalid. Note that if uploading to an
analysis prep via the Software Risk Manager API, the analysis prep is still considered inactive until
the upload finishes. It is possible for the analysis prep to expire before the upload finishes. If you're
encountering an error from the API stating the prep doesn't exist, it is recommended to increase the
default of this prop. A value for this property should follow the form of {number}{unit}, for example,
50m for 50 minutes or 1h for 1 hour.
• srm.correlation.default-component-correlation-mode (default:
vulnerability,identifier,type) - this setting configures what the default component correlation
mode will be for newly created projects in SRM. Valid values are
• vulnerability,name&version,type
• vulnerability,identifier,type
• identifier,type
• name&version,type
• vulnerability,type
• code-metrics.keep-all-logs (default: false) - this setting determines whether to keep all the log
files for the code metrics tools that Software Risk Manager runs. If false, only the logs from failures are
kept.

Bundled Tools
Software Risk Manager bundles various tools that run independently during the analysis process. Each of
these tools requires a memory budget during its own analysis. The memory requirements vary based on
the sizes of the codebases the analyzers are checking. The memory budget for each of these tools is
configurable in the properties file; each of the following settings specify the number of megabytes allotted
to their respective tools. In general, the static analyzers will require more memory in order to analyze larger
projects.

• java.tools.maxmemory (default: 1024 (1GB)) determines the maximum heap size for java-based
tools.
• java.tools.maxmemorypercentage (default: <none>) determines maximum heap size for java-
based tools as a percentage of total system memory.
• ruby.tools.maxmemory (default: 1024 (1GB)) determines the maximum heap size for Ruby-based
tools, which are run with Java via JRuby.
• ruby.tools.maxmemorypercentage (default: <none>) determines the maximum heap size for
Ruby-based tools as a percentage of total system memory, which are run with Java via JRuby.
• php.tools.maxmemory (default: 1024 (1GB)) determines the maximum heap size for PHP tools.

Additionally, these bundled tools may be disabled entirely, if necessary, by setting bundled-
tools.disable to true (default: false). When this flag is set, no bundled tools will be available on the
new analysis page nor will they be run.

463
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Report Configuration Templates

Several report configuration options accept templates for their values. These templates may contain plain
text and various substitutions, surrounded by {{ and }}. To include a { } or \, prefix them with a
backslash (e.g., {).
The available substitutions are as follows:

• {{report.name}} or {{report.type}} - the type of report, e.g., 'PDF.'

• {{report.title}} - the title of the report, e.g., 'Assessment Report' or 'HIPAA Report.'
• {{project.id}} and {{project.name}} - the ID or name of the project the report was generated
for.
• {{user.name}} - the display name of the user who generated the report.
• {{date:pattern}} - the current date/time formatted with the given pattern; details on acceptable
patterns may be found here.

Software Risk Manager users may also include project metadata values as well:

• {{meta:foo}} or {{metadata:foo}} - provides the contents of the metadata field named "foo" for
the project (or a blank string if that value is not specified).
• {{meta.id:bar}} or {{metadata.id:bar}} - provides the ID of the chosen metadata value for
the field named "bar" (or a blank string if one was not given).

The following modifiers may be applied to any value:

• ltruncate:length - will take up to the last length characters (truncated from the left of the string).
• truncate:length or rtruncate:length - will take up to the first length characters (truncated
from the right of the string).
• labbreviate:length - will take up to the last length characters, inserting an ellipsis on the left if
the string was truncated.
• mabbreviate:length or cabbreviate:length - will take up to length characters from the string,
inserting an ellipsis in the center of the string, if necessary.
• abbreviate:length or rabbreviate:length - will take up to the first length characters,
inserting an ellipsis on the right if the string was truncated.

For example, {{project.name|abbreviate:8}} will limit the length of the project name to the first 5
characters followed by an ellipse. A project name of "My Project" would be truncated to "My Pr..." for
display purposes.

Report Filename
The template used to generate filenames for reports may be customized. This can be done by setting the
report.filename-template property. See the previous section for details on valid values.
The default template is {{project.name}} ({{date:dd MMM YYYY}}) - which will produce
filenames such as "My Project (27 Mar 2017).xml."

464
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Custom Logo
Users can add their company logo to a PDF report through a prop setting in codedx.props. The custom
logo will appear on the cover of the PDF report. You can place the logo in the same folder as the properties
file or specify an absolute path. For best results, the specified image should be at least 432 pixels wide
and/or 144 pixels tall.
For an image file named "logo.png" placed in the same folder as the properties file, the setting in
codedx.props would be as follows:

report.pdf.custom-logo = logo.png

Finding Search

On the Findings Page, the Search area lets you filter findings based on metadata fields from their results,
specifically, "Evidence" on the Details Page. The fields presented in the Search dropdown are the
intersection of the set of fields present in that project and the set of fields present in a "for display" whitelist.
The "for display" whitelist can be augmented via configuration:

• additional-values.extra-for-display [default: N/A] - a comma-separated list of result

metadata fields that you want to appear in the Search dropdown. Leading and trailing spaces around
each entry in the list will be trimmed. For example, Field 1, Field 2 , Field 3 will be
interpreted as a 3-item list; Field 1, Field 2, and Field 3.

Note: When searching based on a result metadata field, you must enter the full case-sensitive value of the
metadata to get a match. For example, searching by Field 1 for abc will not match a Field 1 with a
value of abc123or ABC.

Tool Configuration

Props Settings
Software Risk Manager has tool-specific settings for some tools, which control how Software Risk
Manager will behave in response to data from those tools.

Veracode
When accessing Veracode via a Tool Connector, it is possible to load "Callstack" information for each
Veracode Flaw. (Veracode Callstack information is interpreted as Software Risk Manager Data Flow
information for the corresponding results.) Doing so will improve the decision-making process of agentless
hybrid correlation, but this comes at a steep performance cost (roughly 1-2 seconds per flaw).

• veracode.callstack-load-enabled enables loading of the optional "Callstack" information when

set to true. Defaults to false.

465
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

NowSecure
NowSecure uses lab-api as the default subdomain for the lab api and app as the default subdomain for
the user interface. Software Risk Manager allows user-defined values for these subdomains in the props
file.

• nowsecure.lab-api-subdomain defines the subdomain for the lab api. Defaults to lab-api.
• nowsecure.lab-ui-subdomain defines the subdomain for the lab user interface. Defaults to app.

Black Duck
When automatically importing projects with parent mapping from Black Duck, Software Risk Manager
omits the top-level Black Duck project group.

• blackduck.project-enumeration.include-top-level-group enables including the top-level

Black Duck project group in SRM parent project mapping when set to true. Defaults to false.

Clang-Tidy
By default, the Clang-Tidy reader parses a certain portion of the input file for format detection. The relevant
properties can be changed according to preferences in the props file:

• clang-tidy.format-detection.max-line-length sets the maximum number of characters to

read per line of the input file. Defaults to 8192 characters.
• clang-tidy.format-detection.num-lines sets the number of lines to read from the input file.
Defaults to 1500 lines.
• clang-tidy.format-detection.patience sets the number of lines to scan before running into a
relevant line for format detection. Defaults to 15 lines.

Clippy
Clippy is a tool for linting Rust code, typically through the Cargo package manager. Software Risk Manager
can run Clippy on Rust code, if available.
When Software Risk Manager is properly configured to use Clippy, it will be offered as a bundled tool when
analyzing a ZIP containing at least one Cargo.toml file. During analysis, Clippy will be invoked for each
Cargo.toml file discovered in the ZIP.
In order for Software Risk Manager to run Clippy:

• The standard Rustup installer must be used and installed in a manner accessible to Software Risk
Manager.
• Clippy must be installed as a Cargo component. Clippy is typically installed as part of Rustup
installation, but it can also be installed manually, if needed.
• Software Risk Manager must be able to discover the installation paths.
• Any additional dependencies needed for building your Rust projects must be pre-installed on the
Software Risk Manager machine.

466
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

The procedure varies by platform as described in the sections below.

Clippy on Linux

These steps should be followed only after Software Risk Manager has been installed.
Note: Rustup must be installed for the user which runs Software Risk Manager.

• For non-root installations, this will be the user that was logged in when Software Risk Manager was
installed. The Rustup installer can be run by that user and installed as usual.
• For root installations, this will be the tomcat user created automatically by the Software Risk Manager
installer. The Rustup installer must be run through a tomcat user session. For example, on Ubuntu,
this may be done with sudo -u tomcat bash to start a new shell as the tomcat user, followed by
the Rustup install command.

This should provide a .cargo folder in the user's home directory that contains the bin/cargo executable
required by Software Risk Manager.
Restart Software Risk Manager and Clippy should be offered as a bundled tool during analysis of relevant
ZIP files.

Clippy on Windows

These steps can be followed before or after Software Risk Manager has been installed.
On Windows, Software Risk Manager runs through the Local Service user, which does not have a
home directory. Instead, these steps will be followed:

• Install Rustup for at least one user on the Software Risk Manager machine.
• Give the Local Service user permission to read, write, and execute content in the .cargo and
.rustup folders in the user's home directory.
• Update codedx.props to provide the path to the .cargo and .rustup folders.

Log in to the Software Risk Manager machine and run the standard Rustup installer as that user. Once
installation has completed, navigate to the user's home directory (Win+R, type %USERPROFILE%, press
enter) and find the .cargo and .rustup folders.
For each folder, do the following:

1. Right-click and select Properties.

2. Go to the Security tab.
3. Click the "Edit" button.
4. Click the "Add" button.
5. In the textbox at the bottom, enter the text "Local Service."
6. Click "OK" to close the "Select User or Groups" modal. The "Local Service" user should now appear in
the list of users.
7. Select the user and enable all permissions except "Full control" and "Special permissions."
8. Click "OK" to close the "Permissions for Folder" window.
9. Click "OK" to close the "Folder Properties" window.

467
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

With these changes, Software Risk Manager will have access to the .cargo and .rustup folders.
Next, open the Software Risk Manager Properties file and add these entries:

cargo.path = C:/Users/<username>/.cargo
rustup.path = C:/Users/<username>/.rustup

... where <username> will be replaced with the name of the user that installed Rustup.
Restart Software Risk Manager, and Clippy should be offered as a bundled tool during analysis of relevant
ZIP files.

Coverity
By default, a finding’s severity in Software Risk Manager is based on the Coverity issue's severity.
"Dismissed" and "Absent Dismissed" issues are also excluded by default from the findings. The relevant
properties can be changed according to preferences in the props file:

• coverity.finding-severity-from-cvss-score determines whether to use the CVSS Score to

configure the finding severity. Defaults to false.
• coverity.include-dismissed-issues determines whether to include Coverity issues with
"Dismissed" status in the list of findings. Defaults to false.
• coverity.include-absent-dismissed-issues determines whether to include Coverity issues
with "Absent Dismissed" status in the list of findings. Defaults to false.

When automatically importing Coverity projects and versions from the integrations page, SRM will attempt
to parse the branch name from the stream name. Coverity stream names must be globally unique, and so
a common pattern is to use the project name, followed by a separator and the branch name. For example,
a project WebGoat with branch main might have a stream named WebGoat-main. By default, SRM will
attempt to determine the branch from the stream name by checking for the project name, followed by a
separator of either -, _, or a space. Additional stream name parsing behavior can be defined with the
following props setting:

• coverity.stream-name-regexes.# defines additional regular expressions to be used for Coverity

stream name parsing. # must be replaced with 0 for the first regex pattern to be defined. If additional
regex patterns are required, each additional one must increment # by one.

The first regular expression to match the stream name in ascending order of their indexes will be used to
determine the branch name. The branch name will be extracted from the first capture group of the
matching regex. If other groups are required, they must be defined as non-capturing groups. Additionally, if
the stream name format includes the project name, {{projectName}} may be used in place of the
project name. When evaluating the regular expressions, SRM will replace any instances of
{{projectName}} with each project name's literal.
For example, consider a project WebGoat with streams WebGoat - main and Webgoat (develop),
where main and develop are the respective branches. The first stream's format may be defined with the
regex {{projectName}} - (.+). The second stream's format may be defined with the regex
{{projectName}} \((.+)\). Both regexes may be defined in the props file by assigning one to the

468
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

property coverity.stream-name-regexes.0, and the other to coverity.stream-name-

regexes.1.

Dynatrace
When ingesting Dynatrace data into Software Risk Manager using the tool connector, it limits the number
of entities and related attacks that are included in each result, since these lists can get overwhelmingly
large. By default, the tool connector also specifies a port for ActiveGate environments, and a page size for
the number of vulnerabilities or attack results to include per page. The relevant properties can be changed
according to preferences in the props file:

• dynatrace.active-gate-environment.port sets the default port number to use for ActiveGate

type Dynatrace environments. Defaults to 9999.
• dynatrace.vulnerabilities.page-size sets the number of vulnerability results to include per
page. Should be between 1 and 500. Defaults to 100.
• dynatrace.max-num-entities sets the maximum number of entities that are included in
vulnerability results. Defaults to 10.
• dynatrace.max-num-attacks sets the maximum number of related attacks that are included in
vulnerability results. Defaults to 10.
• dynatrace.attacks.page-size sets the number of attack results to include per page. Should be
between 1 and 500. Defaults to 100.

SD Elements
Regulations Sections data from SD Elements can be pulled in by SRM based on a configuration setting
defined in codedx.props. To pull in this data, set the property sdelements.fetch-regulation-
sections to true. (The default setting is false.)

Note: The default is set to false due to a known issue with SD Elements that requesting Regulations
Sections data causes errors.

Configuration Files
For some of the bundled tools, Software Risk Manager provides the ability to define a configuration file,
either system-wide or on a per-project basis. Within the Software Risk Manager appdata directory, locate
the tool-data directory (or create it if it isn't present). To define a configuration file for a tool, create a
directory with that tool's name (as specified below). A system-wide configuration should be placed in that
directory, or, for a per-project config, create a sub-directory named with the given project's ID, and then
place the configuration file in that sub-directory.

Scalastyle
Software Risk Manager supports user-defined config.xml scalastyle config files. Place the file within the

469
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

tool-data/scalastyle directory or within a project-specific subdirectory. Files should follow the format
defined by scalastyle.
Software Risk Manager also supports a user-defined scalastyle.props config file for configuring the
JVM environment in which the scalastyle tool runs. Currently, the only supported property is
file.encoding, which will be passed to the JVM via the -Dfile.encoding environment variable. This
allows you to run scalastyle on projects that don't use the standard encoding.

Checkstyle
Software Risk Manager supports user-defined config.xml Checkstyle configuration files. Place the file
within the tool-data/checkstyle directory or within a project-specific subdirectory. Files should follow
the format defined by Checkstyle.

Cppcheck
Software Risk Manager supports a user-defined cppcheck.conf config file. Create the file in the tool-
data/cppcheck directory or within a project-specific subdirectory. Within that file, you can define a value
for the useThreads property (e.g., useThreads=4 to request that Cppcheck use four threads). Also,
Cppcheck will run with the --inline-suppr option enabled by default, allowing you to suppress errors
from within your source code. This behavior can be disabled by setting inlineSuppression=false.
See the Cppcheck Manual for more details on these settings.
You can also choose to define the platform property. This affects Cppcheck's configuration for platform-
specific types and sizes. By default, Cppcheck will choose the platform your Software Risk Manager server
is running on. Available platform options are as follows:

• unix32 32 bit Unix variant

• unix64 64 bit Unix variant
• win32A 32 bit Windows ASCII character encoding
• win32W 32 bit Windows UNICODE character encoding
• win64 64 bit Windows
• avr8 8 bit AVR microcontrollers
• native Type sizes of host system are assumed, but no further assumptions
• unspecified Unknown type sizes

You can also use the libraries property to specify a list of library configurations for Cppcheck to use.
For example, setting libraries = [gtk, posix, qt] will enable Cppcheck's library configurations
for gtk, posix, and qt. The available configurations are avr, bento4, boost, bsd, cairo, cppcheck-lib, cppunit,
daca, dpdk, embedded_sql, emscripten, ginac, gnu, googletest, gtk, icu, kde, libcerror, libcurl, libsigc++,
lua, mfc, microsoft_atl, microsoft_sal, microsoft_unittest, motif, nspr, ntl, opencv2, opengl, openmp,
openssl, pcre, posix, python, qt, ruby, sdl, sfml, sqlite3, tinyxml2, vcl, windows, wxsqlite3, wxsvg,
wxwidgets, and zlib.

JSHint
Software Risk Manager supports a user-defined jshint.conf config file. Create the file in the tool-

470
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

data/jshint directory or within a project-specific subdirectory. Within that file, you can define a value for
the scan-html property, which tells JSHint to additionally scan .htm and .html files. This property is
enabled by default (i.e., scan-html=true).
You can also define a value for the extract property, which sets the value for the --extract flag from
JSHint. This flag controls how JSHint extracts HTML from files. Available extract options are as follows:

• auto JSHint will attempt to extract javascript only if the file looks like it is an HTML file. This is the
default value (i.e., extract=auto).
• always JSHint will always attempt to extract javascript. Note that if this value is set, JSHint will scan all
files as HTML. This means that javascript source files will not be scanned normally. Instead, JSHint will
search them for HTML to extract and anything else in the file will be ignored.
• never JSHint will never attempt to extract javascript. Note that if this value is set, JSHint will not be
able to scan HTML. scan-html must be set to false, otherwise JSHint will try to scan HTML files as
javascript source and will report an error for each one.

PHPMD
Software Risk Manager supports user-defined config.xml PHPMD ruleset files. Place the file within the
tool-data/phpmd directory or within a project-specific subdirectory. Files should follow the format
defined by PHPMD.

PHP_CodeSniffer
Software Risk Manager supports user-defined config.xml PHP_CodeSniffer ruleset files. Place the file
within the tool-data/phpcodesniffer directory or within a project-specific subdirectory. Files should
follow the format defined by PHP_CodeSniffer.

PMD
In Software Risk Manager's config file in the tool-data/pmd directory or within a project-specific
subdirectory, you can define a value for the debug-logging property (e.g., debug-logging=true to
enable verbose PMD logs). You can also define a value for the encoding property (e.g.,
encoding=UTF-8 to set the character encoding PMD expects source to be in. Acceptable values are any
standard java.nio.charset.Charset character set). By default, these are debug-logging=false
and encoding=UTF-8.

ESLint
By default, Software Risk Manager will pass --ignore-pattern **/node_modules/*.
Configuration
Software Risk Manager supports user-defined .eslintrc and .eslintignore ESLint config files.
Place the file(s) within the tool-data/eslint directory or within a project-specific subdirectory. Files
should follow the format defined by ESLint. You can use the js, yml, json, or eslintrc formats.
In the event that there are multiple config files present in different formats, Software Risk Manager will

471
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

follow the same priority that ESLint uses. ESLint will also use any .eslintrc config files uploaded in the
project as defined by the rules explained here.
Additionally, Software Risk Manager will search for an .eslintignore file in the root directory of the
uploaded zip file. The .eslintignore file in the zip will take precedence over the .eslintignore file
in the tool-data/eslint or project-specific directories. If you use a custom config, be sure to adjust
your tool configuration. By default, only the recommended ESLint rules are enabled.
Software Risk Manager also supports user-defined "appdata-dir.dita"he default eslintrc.json file. For
users wanting to add minor adjustments to the default configuration, a eslint-config-extra.js can
be placed within the tool-data/eslint directory or within a project-specific subdirectory (a directory
whose name is the numeric id of the Software Risk Manager project), as with the custom .eslintrc and
.eslintignore files mentioned above. When running ESLint, SRM will search for this "extra" config file
and, if present, will include it as an extension of its default ESLint config file.
The contents of the eslint-config-extra.js file should be in the form module.exports = { ...
}, where the ... is replaced by your custom configuration as defined in the ESLint configuration guide.
Important notes about using a custom .eslintignore file

• If an .eslintignore file is neither found in the uploaded zip file nor provided in the tool-data/
eslint directory, Software Risk Manager will pass --ignore-pattern **/node_modules/* as a
command-line argument to ESLint.
• If you want to provide an .eslintignore file, it is a good idea to include the **/node_modules/*
pattern in that file; linting the contents of your third-party dependencies is not recommended, due to the
fact that in some cases this can cause ESLint to fail.

Several ESLint plugins are made available when running as a bundled tool in Software Risk Manager:

• eslint-plugin-security: enabled by default

• eslint-plugin-scanjs-rules: disabled by default
• eslint-plugin-no-unsanitized: enabled by default
• eslint-plugin-xss: enabled by default
• eslint-plugin-html: enabled by default
• eslint-plugin-react: enabled by default
• eslint-plugin-react-hooks: enabled by default
• eslint-plugin-n: enabled by default; replaces eslint-plugin-node
• eslint-plugin-node: disabled by default
• eslint-plugin-import: enabled by default
• eslint-plugin-flowtype: enabled by default
• eslint-plugin-jsx-a11y: disabled by default in Software Risk Manager Tool Configuration
• @stylistic/eslint-plugin-js: disabled by default
• @babel/eslint-parser: default Software Risk Manager parser

Any of these plugins can be used in or excluded from your user-defined configs. All plugins use their
default or recommended rules and settings, except for no-location-href-assign from eslint-plugin-
xss. For this rule, Software Risk Manager uses encodeURIComponent for the escapeFunc option
instead of the default escape function, which has been deprecated. More information about how to
configure these plugins can be found on their respective npmjs or GitHub pages.
By default, Software Risk Manager will run ESLint on .js, .html, and .htm files. If you want to change

472
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

this behavior, you can specify a comma-separated list of file extensions with the eslint.extensions
setting in your codedx.props file. You do not need to include the . with each file extension
(eslint.extensions = js,html,htm). Note that if you decide not to use the html plugin in your
custom configs, you must use this setting to specify that you want ESLint to only run on .js files.
Otherwise, it will try to scan any .html and .htm files it finds as javascript, which will cause ESLint
parsing errors.
Custom Plugins and ESLint Installations
Software Risk Manager allows you to install third-party ESLint plugins, shareable configs, and parsers. To
do so, first make sure you have npm installed and accessible from the command line by installing Node.js.
Then, open a command line and navigate to the tool-data/eslint directory or a project-specific
subdirectory. From there, you can install any plugins, shareable configs, and parsers you wish to use by
running the command npm install ... --save. You do not need to install any of the plugins that are
included with Software Risk Manager by default.
If you want to use your own ESLint environment, you can specify the path to it in your codedx.props file
with the eslint.path setting. Software Risk Manager expects that the provided directory will point to the
folder containing ESLint's bin folder. Software Risk Manager will also try to find any of the supported
ESLint config files in this directory. Note that if you use the global or project config files as described
above, they will take precedence over the ones in this folder. Also, when using an external installation,
Software Risk Manager will ignore any custom plugin folders in the tool-data/eslint directory.

ZPA
Software Risk Manager supports user-defined forms-metadata.json ZPA Oracle Forms metadata
files. Place the file within the tool-data/zpa directory or within a project-specific subdirectory. Files
should follow the format defined by ZPA.

STIG
By default, the STIG reader only ingests vulnerabilities with Open and Not Reviewed status. The
following properties can be configured in the props file to also ingest other statuses if required:

• stig.status.include-not-a-finding determines whether to ingest vulnerabilities with Not A

Finding status. Defaults to false.
• stig.status.include-not-applicable determines whether to ingest vulnerabilities with Not
Applicable status. Defaults to false.

JVM System Properties

You can set custom system properties for the JVM process that hosts Software Risk Manager. To do so,
use the prefix codedx.jvmprops. on a line in your codedx.props file. For example, to set the
http.proxyHost system property to 1.2.3.4, add the following line:

codedx.jvmprops.http.proxyHost = 1.2.3.4

473
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Note that specifying a setting this way will overwrite existing settings in the JVM. For example, it is possible
to overwrite the user.home property, which may be used by logic within Software Risk Manager. Use care
that you don't overwrite an important value.
For a non-exhaustive list of system properties to be aware of, see https://docs.oracle.com/javase/tutorial/
essential/environment/sysprop.html.

Proxies

Some features, like JIRA Integration and Tool Connectors, reach out to third-party programs via HTTP(S).
If your Software Risk Manager server is running behind a proxy, you can configure Software Risk Manager
to use that proxy for communications with these programs by setting the appropriate properties:

• proxy.host - The hostname, or address, of the proxy server, e.g., 1.2.3.4 or

myproxy.mydomain.com.
• proxy.port - The port number of the proxy server (default: 80).
• proxy.username - The username for authentication, if necessary.
• proxy.password - The password for authentication, if necessary.
• proxy.nonProxyHosts - A |-separated list of hosts that should be accessed without going through
the proxy. (default: localhost|127.*|[::1])

A typical proxy configuration in your codedx.props file would resemble the following:

proxy.host = 123.234.156.178
proxy.port = 3128
proxy.username = myproxyuser
proxy.password = myproxypassword

Visual Log Configuration

By default, the visual log will not record successful-login events. To enable this, set the
auth.logging.recordSuccess = true.
Note: Changing this property will not retroactively reveal successful logins that occurred previously, as this
setting determines whether to record successful logins, not whether to show them.

Tool Orchestration Configuration

When Software Risk Manager is deployed on a Kubernetes cluster, you can run orchestrated analyses
using the Software Risk Manager Tool Orchestration. If you have a Software Risk Manager license that
includes Tool Orchestration, enable the feature when you run the Helm Prep Wizard.

474
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Analysis Cleanup
By default, Software Risk Manager will remove old analyses and related storage from the tool service
automatically. You can customize or disable this behavior with the following options in the codedx.props
file:

• tws.storage.cleanup.enabled = true - sets whether to enable automatic analysis cleanup

[default: true].
• tws.storage.cleanup.max-total-analyses = 100 - sets the maximum number of
orchestrated analyses to keep; further analyses will cause the oldest to be deleted [default: 100].
• tws.storage.cleanup.max-analyses-per-project = 5 - sets the maximum number of
orchestrated analyses to keep per-project; further analyses will cause the oldest in the project to be
deleted [default: 5].

Note: Both successful and failed analyses count toward the "total" being tracked.

Issue Tracker Configuration

To support issue tracker integrations, Software Risk Manager will make requests to the issue tracker
server periodically in order to create, update, and read issues. Due to the volume of requests that can be
made in quick succession, issue tracker servers may begin to deny requests to prevent the server from
being overloaded.
The following properties will affect how Software Risk Manager makes requests.

• azure.auto-create-delay [default: 50] - sets the delay (in ms) between subsequent work item
creation requests made during an auto create job.
• gitlab.auto-create-delay [default: 60] - sets the delay (in ms) between subsequent requests
made during auto create jobs and bulk update jobs.
• jira.auto-create-delay [default: 50 - sets the delay (in ms) between subsequent issue creation
requests made during an auto create job.
• servicenow.request-delay [default: 750] - sets the delay (in ms) between subsequent requests
made during auto create jobs and bulk update jobs.

Machine Learning Triage Server Memory Usage

The Software Risk Manager machine learning aided triage functionality is handled by a separate process,
the Machine Learning Triage Server, which Software Risk Manager spawns and manages. Training a new
prediction model is computationally intensive and can use large amounts of memory. There are times
where training performance can be improved with the availability of more memory. The upper bound on the
amount of memory that the Machine Learning Triage Server JVM can use during training and making
predictions can be configured by setting the following properties setting:
mltriage.service.maxheap [default: none] - sets the max heap size (in megabytes) of the Machine
Learning Triage Server JVMs.

475
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Automatic Updating of the Software Risk Manager Prediction Model

Software Risk Manager can automatically update your prediction model. This feature can be configured or
turned off completely by setting the following props settings in your codedx.props file:

• mltriage.enable-periodic-retrain [default: true] - enables Software Risk Manager to

periodically train a prediction model.
• mltriage.model-train-time [default: 01:45:00] - the time at which Software Risk Manager will
check if the threshold set in mltriage.retrain-threshold has been met, and if it has, train a prediction
model.

Secure Code Warrior

Software Risk Manager integrates with Secure Code Warrior to provide developers with resources to help
facilitate the learning of secure coding practices. This feature can be disabled by setting the following
props setting in your codedx.props file:

• codedx.scw.enabled [default: true if offline mode is off, false otherwise] - enables the Software Risk
Manager Secure Code Warrior integration and its relevant features.

Software Risk Manager Scoring Calculations

In analysing risk, Software Risk Manager calculates a "code score" (Critical, High, Medium, and Low) by
averaging a "custom code score" and a "component score." This is done through a configurable function in
the form f(severity, count) for certain metrics (shown below). However, this formula can be
customized if needed. (For more information on Risk Scoring, see the Risk Score section in the User
Guide.)
The metrics used for this calculation are as follows:

• componentFindingVolume - in which the count represents the number of component findings for a
given severity.
• customCodeFindingVolume - in which the count represents the number of non-component findings
for a given severity.
• customCodeFindingVariety - in which the count represents the number of finding types for a given
severity.

These metrics are used to calculate a "penalty," which is removed from a top score of 100 down to a
minimum score of 0. The "component score" uses the first of the metrics listed above; "custom code score"
uses the sum of the other two.
The f function can be configured by name; for example, the base config path for the
componentFindingVolume formula would be dashboard.score.componentFindingVolume.
Once the function is configured, there are three suffixes that control the formula:

• .formulaType
• If set to log, the formula is (severity, count) => log_<logBase>(count) *

476
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

criticalWeight / (critical - severity)^2

• If set to linear, the formula is (severity, count) => count * criticalWeight /
(critical - severity)^2
(The customCodeFindingVolume metric uses the log formula by default, while the rest use
linear.)
• .criticalWeight represents how much weight a Critical severity holds in the formula. "High" will
have 1/2 the weight; "Medium," 1/4. (The default is 3.0.)
• .logBase is used as the base number for the log function in the log formulaType; for example, log-
base-2 or log-base-10. (The default is 2.0.)

Here is an example of a default configuration for the componentFindingVolume metric:

dashboard.score.componentFindingVolume.formulaType = log
dashboard.score.componentFindingVolume.criticalWeight = 3.0
dashboard.score.componentFindingVolume.logBase = 2.0

SMTP Configuration

To support policy email notifications, a valid SMTP configuration is required. The following properties are
used to configure SMTP:

• smtp.sender - [required] the address the email is being sent from.

• smtp.host - [required] the SMTP server being used to send email.
• smtp.user - the username for the SMTP server, if authentication is required.
• smtp.password - the password for the SMTP server, if authentication is required.
• smtp.oauthToken - the OAuth 2.0 access token for the SMTP server, if authentication is required.
• smtp.port - [default: 25] the port of the SMTP server.
• smtp.auth - [default: false] true/false, if authentication is being used.
• smtp.tls - [default: false] true/false, if TLS is being used.
• smtp.additionalProps - a list of additional SMTP properties to configure the SMTP server. These
are expected as comma-separated key -> value pairs. For example: smtp.additionalProps =
mail.smtp.ssl.enable -> true, mail.smtp.ssl.trust -> * You can refer to the full list of
available SMTP properties here.

Host Normalization

Host normalization can be configured via the following props:

• host-normalization.use-srm-tracking – [default: false] Whether or not SRM should use native

host tracking and ignore externally reported host tracking methods.

477
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Webhook Configuration

Webhooks can be configured via the following props:

• webhook.finding-chunk-size – [default: 100] The maximum number of findings in a payload per

request.

Polaris Assist

Polaris Assist can be configured using the properties listed below. For more information, see AI Insight
Using Polaris Assist in the User Guide.

Properties Settings
The following properties can be set in the Software Risk Manager properties file:

• assist.model-id [default: 'gpt-4o'] - The ID of the LLM that will be requested by SRM.
• assist.code-context.max-lines [default: 100] - The maximum number of lines of code to
include as context for requests to the LLM (including the line range indicated by the finding and any
surrounding lines).
• assist.code-context.max-chars [default: 2048] - The maximum number of characters of
code to include as context for requests to the LLM.
Lines of code will be excluded entirely if they would be truncated by this limit. For assessments on
minified files that consist of a single line, this typically prevents code from being included at all.
• assist.max-response-tokens [default: 100] - The number of response tokens to request
from the LLM for each assessment.
• assist.max-file-size [default: 500000] - The maximum file size (in bytes) of a source file
that may be read to build the code-context for requests to the LLM.
Source files which exceed this size will not be used when making requests to the LLM, regardless of
assist.code-context settings.

Model ID, LLM API

SRM supports connection to Azure OpenAI APIs, making requests to {Azure OpenAI URL}/openai/
deployments/{model-id}/completions with an api-key header.
Polaris Assist has been tested and validated with base models of GPT-3.5 Turbo, GPT-4, and GPT-4o. We
do not recommend fine tuning or the use of other models.

Azure OpenAI
For installations connecting directly to Azure OpenAI, model-id will be the "Deployment name" of the
model deployed with Azure OpenAI Studio. SRM does not use batch APIs, and the model's deployment
type in Azure OpenAI Studio must not be "Batch."

478
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Install Guide

Customizing the Policy Email Template

Software Risk Manager allows notifications to be sent by email when policy status changes. (To enable
email notifications, see Configuring Email Notifications in the SRM User Guide.) There are three standard
email templates, which can be customized as needed.
To customize a policy email template:

1. Navigate to the AppData folder and locate the template files.

There are three generic email templates, and each one is based on a policy violation status:
• error-builtin-template.json
This file is used to notify the user that a policy has been violated.
• success-builtin-template.json
This file is used to notify the user that the policy violation has been resolved.
• warning-builtin-template.json
This file is used to notify the user that a policy has a violation risk.
(For more information on the SRM AppData directory, see Understanding the AppData Directory.)
2. Open the file you want to customize using any text editor.
3. Make changes to the text as needed.
Changes should be limited to the actual text; variables or references, such as \"{project-name}\",
should not be altered.
4. Save the file using the form *-custom-template.json.
Say, for example, you want to customize the "error" email template. You would locate the file error-
builtin-template.json, edit the file, then save it as error-custom-template.json.

Configuring Automatically Deactivating Users

SRM can automatically deactivate inactive users. The following props can be configured:

• maintenance.deactivate-inactive-users.enabled - [default: false] set this to true to have

SRM automatically deactivate inactive users.
• maintenance.deactivate-inactive-users.scheduling-strategy - [default: daily] defines
when the job will be ran. Allowed values are `daily` and `interval.`
• maintenance.deactivate-inactive-users.run-time - [default: 00:00:00] the exact time when
this job will run. Only used when `maintenance.deactivate-inactive-users.scheduling-strategy` is set to
`daily`.
• maintenance.deactivate-inactive-users.interval - [default: 24 hours] the interval of time
in which this job run. Only used when `maintenance.deactivate-inactive-users.scheduling-strategy` is
set to `interval`.
• maintenance.deactivate-inactive-users.after-days - [default: 30] the number of days a
user can be inactive before this job will automatically deactivate them. A user is considered active if
they have either logged in or have been activated within this number of days.

479
Software Risk Manager Documentation (v2025.3.5)

3
Software Risk Manager Plugins Guide
Software Risk Manager Plugins

There are a number of plugins available to make it easier to bring the power of Software Risk Manager to
other software development tools, including IDEs, CI/CD Build Systems, and open source Application
Security Testing tools. This guide includes instructions for installing and using these plugins.
Note: SAML authentication isn’t currently supported for Software Risk Manager plugins.

Jenkins

The Software Risk Manager Jenkins plugin integrates the Jenkins continuous integration platform with your
Software Risk Manager server. It allows you to push build results to your Software Risk Manager server as
part of the build process.
A Software Risk Manager project and an API key are required. The API key must have the create role for
the project.
This section of the Plugins Guide explains how to install and use the Jenkins plugin. For more information
you may visit the Official Code Dx Jenkins Wiki Page or our GitHub Repository. This plugin is open source
and we welcome community involvement.

Installation

The Software Risk Manager Jenkins plugin is available for installation through the Jenkins plugin
management page. You must be running Jenkins version 2.200 or later, or one of the LTS releases listed
here.

480
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Job Configuration

The first thing you should do is configure your Jenkins Job to publish to Software Risk Manager.
Instructions for Freestyle and Pipeline projects are fairly similar; a note on configuring for Pipelines projects
can be found below.

481
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

This is accomplished on the configuration page by going to Post-build Actions (toward the bottom) and
selecting the Publish to Code Dx option from the Add post-build action button.

You can use the new action to setup different options related to Software Risk Manager.

Publishing
The Server URL, Server API Key, and Code Dx Project fields are required for publishing. Ask your

482
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Software Risk Manager administrator to generate the server API key that has the create role for the
project it needs to interact with.

It is highly recommended that you specify an HTTPS URL, since using HTTP is insecure. If you receive a
warning regarding an invalid certificate, refer to the section on self-signed certificates.
The Server API Key must be stored in Jenkins as a "Secret Text" credential accessible to the Jenkins
project.

483
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Once the Server URL and Server API Key fields are populated, the Code Dx Project dropdown can be
used to select the Software Risk Manager project which will receive analyses. This dropdown has the
options "Specific Project" and "Named Project".
The default option, "Specific Project", provides a simple dropdown for selecting an existing project in
Software Risk Manager. The exact, selected project will always be used when publishing results from the
job, even if the project is renamed.
The "Project Name" option allows you to specify a Software Risk Manager project by name. This must
resolve to exactly one SRM project when the Jenkins job runs, otherwise the job may fail.
The "Project Name" option also offers a "Auto-Create Missing Projects" field option, which allows the
plugin to create the project in Software Risk Manager if it does not yet exist. If using Software Risk
Manager version 2022.4.3 or later, the default branch for the new project will be set to the "Base Branch"
(see below) if specified. Note: The API Key must have either the "Administrator" or "Project Administrator"
role to create projects.

484
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

The Source and Binary Files field allows you to identify the files in the job workspace for Software Risk
Manager to analyze. The format of this field is a comma-separated list of Ant glob file location patterns.
You can populate this list by specifying the files (relative to the workspace) that will be sent to Software
Risk Manager. By default, this field is set to ** (all files).

The Include Git Source option can be used to have Software Risk Manager download the latest content
from the Software Risk Manager project's configured Git source as part of the analysis. Bundled tools will
be ran on this content as usual.
You can use the field "Specific Branch Name" to change which branch is fetched. If left empty, the default
branch for the project will be used.

In addition to generic listing formats, Software Risk Manager supports importing the results of more than
100 commercial and open source analysis tools. This importing feature is defined in the Jenkins plugin
through the Tool Output Files field, where you specify a comma-separated list of the paths and filenames
of each output file. These paths should be relative to the job workspace.

485
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Software Risk Manager users have access to the "First Seen by SRM" and "Last Modified" filters on
Software Risk Manager's Findings page. Each analysis in those filters can have an Analysis Name, which
is directly related to the Analysis Name field in Jenkins. The Analysis Name field lets you set a "name" for
each Software Risk Manager analysis published from Jenkins. You can use build/environment variables to
construct a different name for each analysis. For example, Build #${BUILD_NUMBER} creates the
analysis name "Build #26" for the 26th build of the project. You can construct links using a syntax similar to
markdown, i.e., [link text](link url). This also works with build variables: Build
[#${BUILD_NUMBER}]($BUILD_URL). Some Jenkins plugins, like the Git plugin, provide "macros"
which allow for some additional customization. In this example, the analysis name will be set to the first
eight characters of the git commit hash: ${GIT_REVISION, length=8}. For more information about
"macros", see the Token Macro Plugin Wiki. Note: the analysis name feature is only supported by Code Dx
versions 2.4.0 and up. If the server you plan to publish to is older than version 2.4.0, the analysis name will
be ignored.

The Target Branch and Base Branch options allow you to set which branch will be used when storing
results in the Software Risk Manager project. The Target Branch typically matches the branch currently
checked out in the Jenkins build, but this isn't a requirement. If the Target Branch is not defined, results will
be stored in the project's default branch.
If the Target Branch doesn't exist yet, it will be created in Software Risk Manager using the given Base
Branch as its parent. The Base Branch is only used for creating new branches, and can be left empty if the
Target Branch already exists.
The Target Branch and Base Branch fields only affect data storage within Software Risk Manager and do
not affect the Jenkins build. When Failure or Unstable conditions are configured in the Jenkins plugin,
findings will be fetched from the Target Branch to validate those conditions (or the default branch if
unspecified).
Note: while branching was added in Code Dx 2022.4.0, this plugin requires 2022.4.3 or later when using
the branching feature. If the server you plan to publish to is older than version 2022.4.3, the Target Branch
and Base Branch fields will be ignored.

The Error Handling field lets you change plugin behavior when an error occurs during communication with
the Software Risk Manager server. This behavior is applied if there are connection issues or the analysis
fails, but is not applied for configuration errors such as an invalid Software Risk Manager project.

486
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

In the Advanced Options section, which is located at the bottom, you may specify source and/or binary
locations to exclude from the analysis.

Clicking the Advanced... button will allow you to enter the files you would like to exclude from the build.
These files are also Ant glob patterns.

Handling a Self-Signed Certificate

If the server hosting Software Risk Manager is using a self-signed certificate, you'll receive a warning:

Clicking the Advanced button will allow you to populate the Self-Signed Certificate Fingerprint field with the
SHA1 fingerprint of the self-signed certificate used by the server. Contact your Software Risk Manager
administrator for the correct value. Or you can navigate to your installation of Software Risk Manager in a
browser, and obtain the fingerprint by following the instructions for your particular browser:

487
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

• Chrome: Click the lock icon or "Not secure" message next to the URL. If the connection is not secure,
click the "Certificate is not valid" section to display a pop-up window. Otherwise, if the connection is
secure, click the "Connection is secure" section and then the "Certificate is valid" section to display a
pop-up window. The SHA1 Fingerprint can be found near the bottom of the pop-up window.
• Edge: Click the lock icon or "Not secure" message to the left of the URL, click on the section
"Connection is/isn't secure", and click the certificate icon at the top-right of the window. The SHA1
Fingerprint can be found near the bottom.
• Firefox: Click the lock icon next to the URL, click the section "Connection (isn't) secure", and click the
More information button. In the new window, click the "View Certificate" button which will open a new
tab. The SHA1 Fingerprint can be found in the "Fingerprints" section.
• Safari: Click the lock icon next to the URL, click Show Certificate, expand the Details section, and the
SHA1 Fingerprint can be found near the bottom.

Once you have the correct fingerprint, populating the Self-Signed Certificate Fingerprint field will allow you
to proceed.

Waiting for Analysis Results

When performing an analysis, the Jenkins Software Risk Manager publisher will zip up the specified
workspace files and send them to the Software Risk Manager server. By default, Jenkins will not wait for
the results of the analysis.
In some cases you will want to wait for the analysis to complete so you may consider the Jenkins job a
success or failure. To take this even further, a team may also want the resulting Software Risk Manager
analysis data to influence the state of the build. Additionally, you may want to see a summary of the
Software Risk Manager build and analysis results within Jenkins, including the resulting Software Risk
Manager tables and graphs. This is all possible by selecting the Wait for Analysis Results checkbox.

488
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Upon enabling this option, a new set of fields will be shown on the configuration page. These fields are
categorized into three sections: Policy Behavior, Build Failure Conditions, Build Unstable Conditions, and
Graph Options.

Policy Behavior
The Software Risk Manager Jenkins plugin can check the project for policy violations after the analysis has
completed and then change the build result if there were violations. For a policy violation to affect the
Jenkins plugin, the violations must meet the following conditions:

1. Be associated with the Software Risk Manager project

2. Have at least one rule where the action is set to "Break build"
3. Meet the "fix by" criteria of that policy rule
4. Have a violation of that specific rule

The "'Break build' Action" field allows you to change the build result that is used when the conditions listed
above are met. However, when set to "No Action," the plugin will not check for policy violations.
See the section on Policy Configuration in the Software Risk Manager User Guide for more information.
Note: the Policies feature is only supported by Code Dx versions 2023.1.0 and up. If the server you plan to
publish to is older than version 2023.1.0, the field will be ignored.

Build Failure Conditions

The Build Failure Conditions section allows you to configure the requirements upon which the build will be
considered a failure. It is important to note that not all findings will be included in this check. By default,
only findings with a status of Assigned, To Be Fixed, Reopened, and Unresolved will be considered.
To only check findings created during the current build, you can select the Only Consider New Findings
checkbox.

489
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

The severity dropdown specifies the range of severities that will cause the build to fail. That is, the build will
be considered a failure if one or more findings are detected with the selected severity range.

Build Unstable Conditions

The Build Unstable Conditions section is identical to the previous section, but configures the requirements
upon which the build will be considered unstable. The severity dropdown has the same options as the
Build Failure Conditions section.

Graph Options
The Software Risk Manager Jenkins plugin will show some helpful graphs on the Job and Build pages

490
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

when the Wait for Analysis Results option is enabled. The number of datapoints in these graphs is
configurable using the Number of Builds in Graph field. To show an unlimited number of datapoints, set this
field to a value less than 2.

Configuring for Pipelines

When configuring your Pipeline project, use the Snippet Generator to easily create a command.
In older versions of Jenkins this can be found at the bottom of the Configuration page for the project.

In newer versions, it's labeled as "Pipeline Syntax" in the menu on the left, containing other project options.

491
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Set the "Sample Step" to "step: General Build Step", and change "Build Step" to "Publish to Software Risk
Manager".
Once selected, you will be given the same configuration options as listed in the previous sections.
Behavior of the Pipeline plugin is the same as the Freestyle one. Customize these options as necessary
and click "Generate Pipeline Script" to create a snippet you can use in your pipeline.

Analysis Results

If the Software Risk Manager Jenkins plugin is configured to wait for analysis results before allowing the
build to complete, it will also show tables and charts on the Job and Build pages.

Finding Tables
The Job and Build pages will display tables that provide a summary of the findings.
These tables show the number of findings for each severity and status. A delta between the current build
and previous build will also be shown, if applicable.
Under the tables there is a link to view the latest results within the Software Risk Manager application.

Finding Graphs
The Job page will show graphs of the findings according to severity and status.

TeamCity

The Software Risk Manager TeamCity plugin integrates the TeamCity continuous integration platform with
your Software Risk Manager server. It allows you to push build results to your Software Risk Manager
server as part of the build process.

492
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

A Software Risk Manager project and an API key are required. The API key must have the create role for
the project.
This section of the Plugins Guide explains how to install and use the TeamCity plugin. For more
information you may visit our GitHub Repository. This plugin is open source and we welcome community
involvement.

Installation

For instructions on how to install the Software Risk Manager TeamCity plugin, please see TeamCity's
official documentation.
The plugin is available on GitHub and TeamCity's plugin marketplace.

Configuration

After installing the plugin, the next step is to add a Software Risk Manager Build Step to your project.
Navigate to the "Build Steps" page for your project and click the "Add build step" button. The "New Build
Step" page will display and a dropdown will ask you to "Choose build runner type". After selecting the
"Code Dx" option, the configuration fields will display.

Publishing
The Code Dx URL, API key, and Project fields are required for publishing. Ask your administrator to
generate an API key that has the create role for the project it needs to interact with.
Once the Code Dx URL and API key fields are populated, the Project dropdown will automatically list the
projects available to the API key. If you receive a warning regarding an invalid/untrusted certificate, refer to
the section on self-signed certificates.
The Source and binary field allows you to identify the files in the job workspace for Software Risk Manager
to analyze. The format of this field is a comma-separated list of Ant glob file location patterns. You can
populate this list by specifying the files (relative to the workspace) that will be sent to Software Risk
Manager.

The Files to exclude field is an advanced option that can be displayed by clicking "Show advanced
options" near the bottom of the page. This field allows you to specify files to omit in the source and binaries
zip file that is uploaded to Software Risk Manager. Ant glob file location patterns are also supported.

Software Risk Manager supports importing the results of more than 70 commercial and open source
analysis tools, in addition to generic listing formats. This feature is supported in the TeamCity plugin via the
Tool output files field, where you specify a comma-separated list of paths and filenames of each output file.

493
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

The Analysis Name field allows you to name the analyses performed by TeamCity. You can find the
analysis names on the "First Seen by SRM" and "Last Modified" filters on Software Risk Manager's
Findings page. You can use build/environment variables to construct a different name for each analysis.
For example, Build #%build.number% creates analysis name "Build #26" for the 26th build of the
project. Clicking the icon next to the input control will list possible values for parameter references. You can
also construct links using a syntax similar to markdown, i.e., [link text](link url).

Handling a Self-Signed Certificate in TeamCity

If the server hosting Software Risk Manager is using a self-signed certificate, you'll receive a warning:

Clicking Show advanced options will allow you to populate the Self-Signed Certificate Fingerprint field with
the SHA1 fingerprint of the self-signed certificate used by the server. Contact your Software Risk Manager
administrator for the correct value. Or you can navigate to your installation of Software Risk Manager in a
browser, and obtain the fingerprint by following the instructions for your particular browser:

• Chrome: Click the lock icon next to the URL, choose the Connection tab and follow the link for
"Certificate Information". Expand the "Details" section; the SHA1 fingerprint is near the bottom.
• Firefox: Click the lock icon next to the URL, choose the Security tab, and click the View Certificate
button. The SHA1 Fingerprint should be at the bottom of the resulting window.
• Safari: Click the lock icon next to the URL, click Show Certificate, expand the Details section, and the
SHA1 Fingerprint can be found near the bottom.
• Internet Explorer: Click on the Certificate Error text to the right of the URL, select the Details tab, and
find Thumbprint and Thumbprint algorithm fields. Ensure that the value of the Thumbprint algorithm field
is "sha1" and use the value of the Thumbprint field.

Once you have the correct fingerprint, populating the Self-Signed Certificate Fingerprint field will allow you
to proceed.

494
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Waiting for Analysis Results

When performing an analysis, the TeamCity build runner will zip up the specified workspace files and send
them to the Software Risk Manager server. By default, TeamCity will not wait for the results of the analysis.
In some cases, you will want to wait for the analysis to complete so you may consider the TeamCity job a
success or failure. To take this even further, a team may also want the resulting Software Risk Manager
analysis data to influence the state of the build. Additionally, you may want to see a summary of the
Software Risk Manager build and analysis results within TeamCity, including the resulting Software Risk
Manager tables. This is all possible by selecting the Wait for results checkbox.

Upon enabling this option, the fields below will be enabled.

The Report archive name field allows you to name the build artifact that the build runner produces. The
artifact is a zip archive that contains an HTML file. This zipped HTML file can be used to configure a build
report tab. The build report tab will display the build statistics tables. If this field is left blank, the build
artifact will not be generated.

The Fail build on severity field allows you to have the build marked as "failed" if Software Risk Manager
reports your project contains findings that match the chosen option. This field is defaulted to "None" and
the build step will finish upon successfully uploading all files to Software Risk Manager. If a different option
is selected, the build step will not finish until the analysis is complete.

The Only fail on new findings option, when checked, means that the build will only be marked as failed if
new findings that match the Fail build on severity option are reported.

495
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Analysis Results

If the Software Risk Manager TeamCity plugin is configured to wait for analysis results, and a name has
been provided to the Report archive name field, you can configure a build report tab for your TeamCity
project.
To create a build report tab for Software Risk Manager in TeamCity, please follow these steps:

1. Configure the Software Risk Manager build runner so that it waits for analysis results
2. Fill out the Report archive name field
3. Run the build
4. On the Edit Build page, add the build artifact to your build artifact paths. The name of the zip archive
should match the configured Report archive name
5. On the Edit Project page, navigate to the Report Tabs section
6. On the Report Tabs section, click the Create new build report tab button
7. In the dialog that opens, fill out the Tab Title field
8. In the Start page field, enter the path to the report. This will look something like [report-archive-
name].zip!codedx-teamcity-report.html
9. Click the Save button
10. Run a new build

The report tab will appear on the Build Results page. It contains a link and tables. Clicking the link will
open the latest results within the Software Risk Manager application. The tables show the number of
findings for each severity and status. If applicable, a delta between the current build and previous build is
included.

Bamboo

The Software Risk Manager Bamboo plugin integrates the Bamboo continuous integration platform with
your Software Risk Manager server. It allows you to push build results to your Software Risk Manager
server as part of the build process.
A Software Risk Manager project and an API key are required. The API key must have the create role for
the project.
This section of the Plugins Guide explains how to install and use the Bamboo plugin. For more information
you may visit our GitHub Repository. This plugin is open source and we welcome community involvement.

Installation

For instructions on how to install the Software Risk Manager Bamboo plugin, please see Atlassian's official
documentation.
The plugin is available on GitHub.

496
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Configuration

After installing the plugin, the next step is to add a Software Risk Manager Scan Task to your project.
Navigate to the "Edit Build Tasks" page for a job for your project and click the "Add task" button. After
selecting the "Code Dx Scan Task" option, the configuration fields will display.

Publishing
The Code Dx URL, API key, and Project fields are required for publishing. Ask your administrator to
generate an API key that has the create role for the project it needs to interact with.
The first thing that should be set up are the Software Risk Manager Server Settings.

Self-signed certificates can also be set up here. If using self-signed certificates, please refer to the section
on self-signed certificates. Otherwise, the field may be left blank.
Once the Code Dx URL and API key fields are populated, Click the Refresh Projects button next to the
Project dropdown.

This will populate the list with the Software Risk Manager projects available to the given API key.
The Source and Binary Files field allows you to identify the files in the job workspace for Software Risk
Manager to analyze. The format of this field is a comma-separated list of Ant glob file location patterns.
You can populate this list by specifying the files (relative to the workspace) that will be sent to Software
Risk Manager.

The Excluded Source and Binary Files field allows you to specify files to omit in the source and binaries zip
file that is uploaded to Software Risk Manager. Ant glob file location patterns are also supported.

497
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Software Risk Manager supports importing the results of more than 70 commercial and open source
analysis tools, in addition to generic listing formats. This feature is supported in the Bamboo plugin via the
Tool Output Files field, where you specify a comma-separated list of paths and filenames of each output
file.

The Analysis Name field allows you to name the analyses performed by Bamboo. You can find the analysis
names on the "First Seen by SRM" and "Last Modified" filters on Software Risk Manager's Findings page.
You can use build/environment variables to construct a different name for each analysis. For example,
Build #${bamboo.buildNumber} creates analysis name "Build #26" for the 26th build of the project.
For information on what environment variables are available, see Bamboo variables.

Handling a Self-Signed Certificate in Bamboo

If the server hosting Software Risk Manager is using a self-signed certificate, you'll have to do some
configuration or the connection to Software Risk Manager will be refused:

Bamboo needs to know that your Software Risk Manager server is trusted. Populate the Self-Signed
Certificate Fingerprint field with the SHA1 fingerprint of the self-signed certificate used by the Software
Risk Manager server. Contact your Software Risk Manager administrator for the correct value. You may
also navigate to your installation of Software Risk Manager in a browser, and obtain the fingerprint by
following the instructions for your particular browser:

• Chrome: Click the lock icon next to the URL, choose the Connection tab and follow the link for
"Certificate Information". Expand the "Details" section; the SHA1 fingerprint is near the bottom.

498
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

• Firefox: Click the lock icon next to the URL, choose the Security tab, and click the View Certificate
button. The SHA1 Fingerprint should be at the bottom of the resulting window.
• Safari: Click the lock icon next to the URL, click Show Certificate, expand the Details section, and the
SHA1 Fingerprint can be found near the bottom.
• Internet Explorer: Click on the Certificate Error text to the right of the URL, select the Details tab, and
find Thumbprint and Thumbprint algorithm fields. Ensure that the value of the Thumbprint algorithm field
is "sha1" and use the value of the Thumbprint field.

Once you have the correct fingerprint, populating the Self-Signed Certificate Fingerprint field will allow you
to proceed.

Waiting for Analysis Results

When performing an analysis, the Bamboo build task will zip up the specified workspace files and send
them to the Software Risk Manager server. By default, Bamboo will not wait for the results of the analysis.
In some cases, you will want to wait for the analysis to complete so you may consider the Bamboo build a
success or failure.

Upon enabling this option, the fields below will appear.

The Build Failure Severity field allows you to have the build marked as "failed" if Software Risk Manager
reports your project contains findings that match the chosen option. This field is defaulted to "None" and
the build step will finish upon successfully uploading all files to Software Risk Manager. If a different option
is selected, the build step will not finish until the analysis is complete.

The Only Consider New Findings option, when checked, means that the build will only be marked as failed
if new findings that match the Build Failure Severity option are reported.

499
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Software Risk Manager Server Defaults

If your team uses one Software Risk Manager server for multiple projects, it may be worth setting up
defaults for that server. This will make it easier in the future to create new Bamboo tasks that publish to
that server. You may set defaults by clicking on the Code Dx Plugin link in the ADD-ONS section of the
Bamboo administration.

Here, you may set defaults for the Software Risk Manager URL, API key, and optionally the self-signed
certificate fingerprint.
Once configured, you may opt to use the default server in your task configuration.

500
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Eclipse

The Software Risk Manager Eclipse plugin streamlines the use of Software Risk Manager within the
Eclipse IDE. Developers can push out new builds for Software Risk Manager analyses and the results can
be viewed from within the IDE.
A Software Risk Manager project is required. To allow users access to the project, they must be assigned
to the project where the user roles are consistent with those within Software Risk Manager.
This section of the guide explains how to install and use the Eclipse plugin. For more information you may
visit the Eclipse Marketplace.
This plugin supports the Eclipse versions Neon and later.

Installation

The Eclipse plugin is installed through the usual plugin installation method. Navigate to Help -> Install New
Software. Then click the Add button to add a new update site.
Enter Code Dx for Name. Enter https://eclipse.codedx.com/ for Location.
Then click OK.
Select the Code Dx plugin and continue with the wizard in order to complete the plugin installation process.

Configuration

To configure the Eclipse plugin, you can either navigate to Window -> Preferences and select Code Dx, or
you can navigate to Code Dx -> Configure. These methods will result in the same preferences section
being shown.

501
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

To configure the Eclipse plugin, provide the Server, Username, and Password. Enter the URL of the
Software Risk Manager server in the Server field. Enter your Software Risk Manager log in credentials in
the Username and Password fields. Verify the Software Risk Manager plugin can communicate with the
Software Risk Manager server by clicking the Test Connection button. A message will appear indicating a
successful connection or explaining why the connection failed.

502
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Views

The Eclipse plugin provides two main views: the Code Dx Findings View and the Code Dx Finding Details
View. Both of these are available by navigating to Window -> Show View -> Other.

503
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

The views will be located under the Code Dx folder.

504
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Findings View

This view displays the findings from the selected project. There are three sections: the findings table, the
summary area, and a toolbar.

The table has columns for many of the finding properties such as:

• Severity (shown using severity icons)

• ID
• Tool

505
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

• Rule
• CWE
• Codebase Locations
• Status

The table can be sorted by any of these columns except the Tool column. Right-clicking on a row provides
a context menu for performing actions on the selected finding.
The summary area is located above the table. It provides the project name, the total number of findings,
and the number of findings for each severity category.

The toolbar buttons include (from left to right) the ability to switch Code Dx projects, show details of a
finding, show remote source code residing on the Code Dx server, show only findings assigned to you,
filter by status, change status, synchronize the Eclipse Package Explorer view with the table contents, and
refresh the table.

Switching Code Dx Projects

The table of findings can easily be changed to show the results of different Code Dx projects. This is done
using the following toolbar button:

A dialog is displayed after you click the Select a Project button. Note that only the projects accessible to
your user credentials (provided during configuration) will be shown in this dialog.

506
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Showing Source Code for a Finding

You can view and edit the local source code for a finding by double-clicking on it, or by right-clicking on the
selected finding and choosing Show Finding in the context menu. The editor view will open with the
associated source code. If there is a line number for the finding, the editor will automatically scroll to that
location.

507
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Showing Finding Details

The details of a finding can be viewed by selecting a row in the table and either using the toolbar button or
the context menu of the row.

Showing Remote Source

It is sometimes useful to see the current version of a source file on the Code Dx server. For example, if the
code local to eclipse is different from the remote code. This can be done by selecting a row in the table
and either using the toolbar button or the context menu of the row.

The file will be downloaded from the Code Dx server and displayed in a read-only editor.

508
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

The title of the editor will be marked with a [Code Dx] label before the filename so that it can be
distinguished from local source.

Filtering Findings
The table can be filtered to show only the findings that are assigned to you (left button) and to hide findings
that have a status of Ignored, False Positive,Fixed, Gone and Mitigated (right button).

Changing the Status of Findings

You can change the status of a single finding or a group of findings. First select the finding(s) then use
either the Change Status dropdown located on the toolbar or the Status option in the context menu.

509
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Sync and Refresh

The Sync button is situated to the immediate right of the Change Status dropdown and is used in
conjunction with the Package Explorer view and editors. With the button enabled, just click a file in the
Package Explorer and the table will display only those findings associated with the selected file. Selecting
an editor window of an open file will do the same.
The Refresh button is located to the right of the Sync button. It is used to refresh the table with the findings
on the Code Dx server.

Finding Details View

The Finding Details view shows a minimal version of the Finding Details page in the Code Dx application.
If you have the update role for a project, you can change the status of a finding in that project and post to
its activity stream.

510
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

The toolbar contains a Sync button. When enabled, selections in the Findings table will automatically
update the information in the Finding Details view.

Markers

The Software Risk Manager Eclipse plugin automatically adds source code markers to help you determine
the location of the findings within the code.

511
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

There are markers in both the left and right gutters. The markers in the left gutter use the Software Risk
Manager severity icons to show the highest level severity on the given line. The markers in the right gutter
show the findings throughout the entire file.
The context menu on the marker will show a submenu for each finding on the given line.

512
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Running an Analysis

If you have the create role on a Software Risk Manager project, you have the ability to perform Software
Risk Manager analyses on that project from within the Eclipse IDE. Just select the Run Analysis option
from the Code Dx menu.

When the dialog is displayed, select the Software Risk Manager project from the dropdown, the Eclipse
projects from the list, and click Run.

513
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

An Eclipse job is created and the progress is displayed in the bottom right corner of the IDE. This will
create a zip file containing all local source code from the configured project and send it to be analyzed by
Software Risk Manager. The Findings table will automatically be updated upon completion of the analysis.

Visual Studio

The Code Sight plugin streamlines the use of Software Risk Manager for developers by allowing them to
push out new builds for analysis and view analysis results from within the Visual Studio IDE.
A Software Risk Manager project is required. To allow users access to the project, they must be assigned
to the project where the user roles are consistent with those within Software Risk Manager.
For information on how to install and use the Code Sight plugin, please refer to the Code Sight
documentation.

Visual Studio Code

The Code Sight plugin streamlines the use of Software Risk Manager for developers by allowing them to
view analysis results from within the Visual Studio Code IDE.
A Software Risk Manager project is required. To allow users access to the project, they must be assigned
to the project where the user roles are consistent with those within Software Risk Manager.
For information on how to install and use the Code Sight plugin, please refer to the Code Sight
documentation.

IntelliJ

The Code Sight plugin streamlines the use of Software Risk Manager for developers by allowing them to
view analysis results from within the IntelliJ IDE.

514
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

A Software Risk Manager project is required. To allow users access to the project, they must be assigned
to the project where the user roles are consistent with those within Software Risk Manager.
For information on how to install and use the Code Sight plugin, please refer to the Code Sight
documentation.

Burp Suite

The Software Risk Manager Burp Suite plugin provides a way to upload Burp Suite findings to your
Software Risk Manager server from within Burp Suite.
A Software Risk Manager project and an API key are required. The API key must have the create role on
the project it needs to interact with.
This section of the Plugins Guide explains how to install and use the Burp Suite plugin. For more
information, you may visit our GitHub Repository. This plugin is open source and we welcome community
involvement.

Installation

The Software Risk Manager Burp Suite plugin is available for download from the BApp Store and from our
GitHub Repository.

BApp Store
To install the Software Risk Manager Burp Suite plugin from the BApp Store, go to the Extender tab in
Burp Suite, click the BApp Store tab, and click on Code Dx.

515
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

On the right panel, click the Install button.

GitHub Repository
The Burp Suite plugin can be found on our GitHub Repository.

516
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

To install the extension, go to the Extender tab in Burp Suite and click Add in the Burp Suite Extensions
section.

Click Select file for the Extension file field and navigate to the burp-extension-assembly jar, then click Next
to load the extension.

517
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Configuration

To configure the Burp Suite plugin, navigate to the Code Dx tab.

The Server URL and API Key are required fields for sending data to Software Risk Manager. Ask your
Software Risk Manager administrator to generate the server API key with the create role for the
project(s) which the plugin must interact with.

518
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Once the Server URL and API Key fields are populated, click the Refresh button to list the projects
available to the API key in the Project dropdown. It is highly recommended that you specify an HTTPS
URL, since using HTTP is insecure.

If you receive a warning regarding an invalid certificate, you will be prompted to Reject, Accept
Temporarily, or Accept Permanently. Accepting temporarily will remember the exception until the session
ends. Accepting permanently will create a .usertrust directory containing the truststore information. On

519
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Windows this will be in your appdata directory, on Mac it will be in the Application Support folder, and on
Linux it will be in the .codedx folder in the home directory.

Sending Results to Software Risk Manager

After scanning with Burp Suite, there are two ways you can send the results to Software Risk Manager.
The first is to choose a Target URL from the list in the Software Risk Manager Settings in Burp Suite. After
performing a scan, click the refresh button to list all of the available targets. Multiple targets can be
selected from the list using Ctrl + Click.
Select the project you would like to use, then click the Send to Code Dx button to send the results.

520
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

You will receive a message indicating whether or not the action was successful.

The second method to send the results is to use the context menu in the Issues panel of the Target view.
To do this, open the Target view and select your target or targets from the Site map.

Select the issues that you want to analyze and right click in the Issues panel. Click the Send to Code Dx
button at the bottom of the context menu.

521
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

A menu will pop up and will ask you to select the Software Risk Manager project. Note that this option is
independent of the project and target settings from the Software Risk Manager view.

As with the previous method, you will receive a message indicating whether or not the action was
successful.

OWASP ZAP

The Software Risk Manager OWASP ZAP plugin provides a way to upload OWASP ZAP alerts to your
Software Risk Manager server from within OWASP ZAP.
A Software Risk Manager project and an API key are required. The API key must have the create role for
the project.
This section of the Plugins Guide explains how to install and use the OWASP ZAP plugin. For more
information, you may visit our GitHub Repository. This plugin is open source and we welcome community
involvement.

522
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Installation

The Software Risk Manager OWASP ZAP extension is available for installation through the OWASP ZAP
Marketplace.

523
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Sending Results to Software Risk Manager

The OWASP ZAP plugin can generate a compatible XML file which can be uploaded manually, or it can
upload a report directly to Software Risk Manager.
To upload a report to Software Risk Manager, select the Code Dx: Upload Report option from the Report
menu.

You will be prompted for the Server URL, API Key and Project. Your settings will be remembered between
sessions and are stored in the codedx.properties file located in the OWASP ZAP folder in your user
directory.

After entering the Server URL and API Key, click the Refresh button to populate the Project dropdown.

524
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

If you receive a warning regarding an invalid certificate, you will be prompted to Reject, Accept
Temporarily, or Accept Permanently. Accepting temporarily will remember the exception until the session
ends. Accepting permanently will create a .usertrust directory containing the truststore information. On
Windows this will be in your appdata directory, on Mac it will be in the Application Support folder, and on
Linux it will be in the home directory.

You will receive a message indicating whether or not the action was successful.

You can generate an XML file for use with Software Risk Manager by selecting the Code Dx: Generate
XML Report option from the Report menu.

525
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

API

The plugin also provides an API to use its functions programmatically. More information on how to use the
ZAP API can be found on the ZAP GitHub Wiki.
Note that as a security measure, ZAP will not include messages with Exceptions by default. If you want to
enable messages, you can check Report error details via API in Tools -> Options -> API.

Actions
uploadReport
Uploads a report to Software Risk Manager. Note that uploading an empty report with no alerts will cause
an Exception to be thrown as Software Risk Manager won't be able to read it and will return a non-200
response.
Parameters

• filePath: Absolute path to the report file

• serverUrl: Software Risk Manager server URL
• codeDxApiKey: Software Risk Manager API Key
• projectId: Software Risk Manager Project ID
• fingerprint: Optional SHA1 hash of an invalid certificate to make an exception for
• acceptPermanently: Optional boolean for if the exception should be stored permanently in a truststore
file.

Returns
OK if the report is uploaded successfully.
generateAndUpload
Generates a Software Risk Manager report, saves it to a temporary file, uploads to Software Risk
Manager, then deletes the file.

526
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Parameters

• serverUrl: Software Risk Manager server URL

• codeDxApiKey: Software Risk Manager API Key
• projectId: Software Risk Manager Project ID
• fingerprint: Optional SHA1 hash of an invalid certificate to make an exception for
• acceptPermanently: Optional boolean for if the exception should be stored permanently in a truststore
file.

Returns
OK if the report is uploaded successfully.
EMPTY if the generated report is empty. The report will not be uploaded to Software Risk Manager.

Views
generateReport
Generates an XML report with request and response data.
Returns
An XML report String.

Splunk

The Software Risk Manager Splunk add-on integrates the Splunk data analysis/monitoring/visualization
platform with your Software Risk Manager server. It allows you to push Software Risk Manager findings to
your Splunk server as Splunk events.
An API key and at least one Software Risk Manager project are required. The API key must have the read
role for each project it needs to interact with.
This section of the Plugins Guide explains how to install and use the Splunk add-on. For more information
you may visit Splunkbase.

Installation

Under Apps in the Splunk home screen, click Find More Apps.

527
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Search for Code Dx and install the Code Dx Add-On.

Configuration

Under Apps in the Splunk home screen, click Code Dx to open the Software Risk Manager add-on.

528
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Go to Configuration and click Add-on Settings. Then input the URL of your Software Risk Manager server.
Keep in mind that your server's URL may or may not have /codedx at the end.
Input your API key.

Click Save.

Handling a Self-Signed Certificate

If the server hosting Software Risk Manager is using a self-signed certificate, you must also populate the
CA Bundle field with the path of a .pem or .cer certificate file. Alternatively (although not recommended),
you can set the value for CA Bundle to ALL to disable certificate verification.

529
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Get a copy of the certificate as a file

The following steps use Windows and Chrome.
Navigate to the page with the untrusted certificate using your browser (i.e. Chrome). Then bring up
Chrome developer tools by opening the Chrome menu (⋮), then going to More Tools -> Developer Tools.

Click the Security tab and click the View certificate button to bring up the certificate details popup.

Go to the Details tab in the Certificate popup and click the Copy to File... button.

530
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Use the Base-64 encoded X.509 (.CER) format, then choose a name and location for the file.

531
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

When you click the Finish button, it should say "the export was successful."

Using Software Risk Manager with Splunk

Getting Software Risk Manager data into Splunk

Go to Inputs and click Create New Input. Then fill out the fields to create your first Software Risk Manager
data input.

532
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Notes:

• Interval determines how often your data input will run (every x seconds)
• If a run's start-to-finish duration exceeds the time specified by the Interval field (for example, if
the Interval is set to 60 and a particular run takes more than 60 seconds to finish), the next run
will wait for that previous run and start as soon as it finishes
• Project Specifier can be a project ID or a special string representation of a set of projects:
• To represent a single project, use that project's ID number, e.g. 12
• To represent all projects, use all
• To represent an arbitrary set of projects, join the IDs of each project with an underscore, e.g.
12_42_123_124
• To include 'descendant' projects, add a d before the IDs of the main projects, e.g. d12 or
d12_42_123_124 (note that there is only one d needed; it applies to each of the specified projects)

533
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

• Detection Method and Severity will filter the data by detection method and severity respectively
• These are both multi-value fields, so if you like you can specify multiple detection methods and/or
severities to filter by

To manage a specific input, click on its Action button, in the rightmost, Actions, column.

From there you are given 4 options:

• Edit: view and potentially edit the input

• Delete: remove the input
• Enable/Disable: toggle whether the input is enabled or not
• Inputs are automatically enabled when first created
• An input will not run if it is disabled
• Clone: create a new input with the same default settings as this input

View your Software Risk Manager data in Splunk

Go to Search and search for whatever Software Risk Manager data you want to find.

source="csv_report" - A simple search to start off with that gets results from all inputs (all inputs

534
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

retrieve data from Software Risk Manager through CSV reports)

By default, the host, source, and sourcetype fields are included in Selected Fields (on the left sidebar
after running a search). You can change which fields are selected by clicking on All Fields (also at top of
left sidebar) and selecting/deselecting fields.

GitHub Action

The Software Risk Manager GitHub Action enables an Action workflow to upload files and initiate a scan
with your Software Risk Manager server.
A Software Risk Manager project and an API key or PAT are required. It must have the create role for the
project.
The Action can be used on any Runner machine type. The machine should have access to your Software
Risk Manager server. If Software Risk Manager is inaccessible to public traffic, we recommend using a

535
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Self-Hosted Runner to run the action.

Instructions for installation and configuration can be found on the Marketplace listing and the GitHub
repository. This plugin is open source and we welcome community involvement.

Black Duck Bridge CLI Command Line Interface

Overview
The Black Duck Bridge CLI Command Line Interface (Black Duck Bridge CLI) allows you to run scans and
receive results from the command line, either by scripting or running the commands manually. Black Duck
Bridge CLI invokes adapters that handle Coverity and Black Duck scanning, along with abstracting the
various extensions and variables for them, so that usually no manual configuration is required.
For more information on Black Duck Bridge CLI and how to use the command line interface, see Using
Bridge CLI with Software Risk Manager.

Configuring Coverity Thin Client for use with Black Duck Bridge CLI and SRM

When you use Black Duck Bridge CLI to start a Coverity static scan, Black Duck Bridge CLI calls the
Coverity Thin Client to manage code capture. Black Duck Bridge CLI uploads the resulting data and
artifacts to SRM.
In some cases a configuration file, usually named coverity.yaml, helps Coverity Thin Client by
providing capture settings.
When to use a Configuration file
A scan is likely to succeed without any intervention for uncompiled languages like Python, JavaScript, and
PHP, because Coverity Thin Client can automatically detect these languages and configure the scan.
Some scans require a configuration file to include project settings or optimize Coverity for best results.
Use a configuration file in the following situations:

• When scanning a compiled language, such as C/C++, C#, Java, and Kotlin, use the configuration file to
provide your build and clean commands.
• When scans for a project have failed or not returned useful results.

Note: Build environment components must be installed and accessible when integrating with compiled
languages, as illustrated in the "Build commands and dependencies for various build systems" section
further down in this guide. If you plan to run build capture, make sure the build tools are installed where
the capture will run.

Things you can specify with the Coverity Thin Client configuration file:

• Your build and clean commands

• Whether source code in a specific language should be captured or excluded.
• A custom compiler configuration. This is helpful if you are compiling C++ and Coverity does not
automatically configure the compiler (for example, when using a GCC cross-compiler).

536
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

How to start a configuration file

Save a coverity.yaml file in your project's root directory and use the following examples to customize
that file. When Coverity Thin Client is called by Black Duck Bridge CLI, it automatically detects the file,
reads the contents, and executes custom configurations.
Basic examples
For more build and clean commands see the reference section at the end of the chapter.
Java with Maven
The following configuration specifies the clean and build commands needed by Maven. The project will be
cleaned by invoking mvn clean and built using mvn install.

capture:
build:
clean-command: mvn clean
build-command: mvn install

About this example:

• This example shows the complete contents of a coverity.yaml file that you can use to test a Maven
project.
• Note that white space matters in YAML files. The three levels of indentation indicate that the build
property is nested under the capture property and build-command and clean command are nested
under build.

Standard Java example

capture:
build:
build-command: javac HelloWorld.java

C# with msbuild

capture:
build:
clean-command: dotnet msbuild /t:Restore;Clean OWASPTop10.SqlInjectio
n.Web.csproj
build-command: dotnet msbuild /t:Restore;Build OWASPTop10.SqlInjectio
n.Web.csproj

C# with dotnet

537
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

capture:
build:
clean-command: dotnet clean Foo.sln
build-command: dotnet build Foo.sln

Executable script as a build command

capture:
build:
clean-command: clean.sh
build-command: build-it.sh

Coverity Thin Client will only accept one build command and one clean command in the config file, but you
can point to a script containing commands if you need more.
Configuration properties
The tables in this section describe each of the keys that can be used in the coverity.yaml file, starting
at the top level with capture.
Capture settings
The following table describes the capture configuration; subsections describe the fields that make up the
Capture type. All the Keys in the first column of this table can be nested directly under the capture key in
the coverity.yaml file. (For example, build can be seen in the first row of the table and is used in the
example immediately above.)

Key Type Description

Specifies that build capture should be used to capture the project
and provides the build configuration to use.
If not specified and the project directory contains compiled source
files, automatic build capture will be used to capture compiled
Build source files in the project directory.
build
Configuration
For compiled languages only: Java, Kotlin, C#, C, C++, Objective-
C, Objective-C++.
See the Build configuration table below for keys that can be
nested under this one.

Specifies the encoding to use when parsing and emitting the

encoding string
source files in C, C++, JavaScript.Default: US-ASCII

Languages Specifies which languages to include or exclude for capture.

languages
Configuration See Language configuration for a list of supported languages.

538
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Key Type Description

Default: all languages are included

See the table in the Language configuration section for keys that
can be nested under the languages key.

Build settings
The following keys can be defined for compiled languages only. All the keys in this table can be nested
directly under the build key in the configuration file.

Key Type Description

Specifies whether to enable or disable the automatic invocation of
Aspnet_compiler.exe for any ASP.NET 4 and earlier Web
aspnet-compiler Boolean
applications that are detected in the build. The output of
Aspnet_compiler.exe is required by the C# security checker.
Required: The build command will be invoked to use build capture to
capture the project.
build-command String
A build command specified on the command-line will override this
setting.

The clean command will be invoked prior to doing build capture to

clean-command String
capture the project.

For example:

capture:
build:
clean-command: dotnet msbuild /t:Restore;Clean OWASPTop10.SqlInjectio
n.Web.csproj
build-command: dotnet msbuild /t:Restore;Build
aspnet-compiler: true

Language configuration
Use the following keys to specify which languages to include or exclude from capture. You may not specify
both fields.
Language strings may be the following:

• apex
• c-family (This family includes C, C++, Objective C, and Objective C++)
• csharp
• go
• java (Includes JSP and android config files)

539
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

• javascript (Includes JavaScript and TypeScript)

• kotlin
• php
• python
• ruby
• swift
• vb (Visual Basic)

The following languages are not supported by the Coverity CLI:

• CUDA
• Fortran
• Scala

Keys in this table can be nested under the languages key, which appears in the first table above and is
nested under the capture key.

Key Type Description

Specifies the languages for which the source code should be included in the
capture.
include Array of String This key is mutually exclusive with the exclude key.
Default: all languages are included.

Specifies the languages for which the source code should be excluded in
the capture.
exclude Array of String This key is mutually exclusive with the include key.
Default: No languages are excluded.

For example:

capture:
languages:
exclude:
- python

Build commands and dependencies for various build systems

You may need to install the machine dependencies in order to run the corresponding build. If build and
clean commands don't work—check for the dependencies.

540
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Minimal Set of
Build
How to Detect Machine Build and Clean commands
System
Dependencies

Look for the presence Maven build tool build-command: mvn -DskipTests
Maven of "pom.xml" files in -DskipITs install
the project directory Java compiler
clean-command: mvn clean

Look for the presence

of "build.gradle" files
in the project directory

Java compiler
build-command: gradlew --no-daemon -x
With a "gradlew" file (Gradle will be test build testClasses
(Linux/Mac) downloaded
clean-command: gradlew clean
automatically)

Gradle
Java compiler
build-command: gradlew.bat --no-daemon
With a "gradlew.bat (Gradle will be -x test build testClasses
file (Windows) downloaded
clean-command: gradlew.bat clean
automatically)

build-command: gradle --no-daemon -x

Without a "gradlew" or Gradle build tool test build testClasses
"gradlew.bat" file Java compiler
clean-command: gradle clean

Look for the presence Make build tool build-command: make

Make of a file called Compiler for the
"Makefile" clean-command: make clean
appropriate language

Look for the presence Ant build tool build-command: ant

Ant
of a "build.xml" Java compiler clean-command: ant clean

Look for the presence build-command: dotnet msbuild /t:Build

MSBuild of files with ".sln" or .NET SDK clean-command: dotnet msbuild
".csproj" extensions. /t:Restore;Clean

build-command: xcodebuild -workspace

Look for the presence <xcodeproj dir> -scheme <scheme> build
XCode of directories ending XCode -UseModernBuildSystem=No
with ".xcodeproj" CODE_SIGN_IDENTITY=
CODE_SIGNING_REQUIRED=NO

541
Software Risk Manager Documentation (v2025.3.5) Software Risk Manager Plugins Guide

Minimal Set of
Build
How to Detect Machine Build and Clean commands
System
Dependencies

clean-command: xcodebuild -workspace

<xcodeproj dir> -scheme <scheme> clean

GCC configuration
The GNU Compiler Collection (GCC) requires its own coverity.yaml configuration settings. To use
GCC, add lines to:

• Specify the GCC compiler using cov-configure.

• Designate the language and CPU target:

cov-configure:
- [ --template, --compiler, arm-linux-gnueabi-gcc, --comptype, gcc ]
- [ --template, --compiler, arm-linux-gnueabi-g+, --comptype, g+ ]

Below is an example coverity.yaml settings block for GCC, telling it to run a make clean then run the
make command in parallel with at least 10 job slots (make -j 10).

C/C++ Cross Compiler coverity.yaml example:

-------------------------------------------
# Coverity configuration file.
# The schema is available here: <install-dir>/doc/configuration-schema.json
capture:
build:
clean-command: "make clean"
build-command: "make -j 10"
compiler-configuration:
cov-configure:
- [ --template, --compiler, arm-linux-gnueabi-gcc, --comptype, gcc ]
- [ --template, --compiler, arm-linux-gnueabi-g+, --comptype, g+ ]

Note: Pay special attention to GCC binary naming conventions if using more than one language and/or
CPU target.

542
Software Risk Manager Documentation (v2025.3.5)

4
Software Risk Manager API Guide
Software Risk Manager API Guide

Software Risk Manager API Schema

543
©2025 Black Duck Software, Inc.
April 28, 2025