Application security center

6 minute read

The application security center dashboard provides a centralized location to review security issues and findings across all assets deployed within an application environment, along with their severity ratings. Unlike the component security center which focuses on individual components, the application security center aggregates security data from multiple assets deployed through your application workflows, and displays comprehensive results with rich contextual information, such as asset deployment details, security tool outputs, and remediation guidance. The security center integrates findings from both implicit security scans triggered by deployments and explicit security analyses configured in your workflows.

On CloudBees platform:

  • Issues are security issues reported by security tools.

  • Findings are individual occurrences of a security issue reported in a branch, file, or code location.

  • Severity is the rating reported by the security tool that discovered the finding.

Use the security center

The security center is only displayed in the navigation once an application has been selected.

To access the security center:

  1. Select an organization.

  2. Select Applications, then select an application.

  3. Select Security center.

Security Center
Figure 1. Security center
  1. The application deployment workflow repository that creates and runs application level workflows. Select the GitHub organization or repository name to navigate to the repository in GitHub.

  2. Select an environment configured for the application.

  3. Review the total number of open findings across the assets deployed in this application, and the number of findings by each severity.

  4. Select to review assets or issues.

  5. Review the total number of findings, grouped by asset subtype. For example, GitHub repository, Bitbucket repository, or binary artifact. Select the number of findings for an asset subtype to filter issues by that subtype.

  6. Filter issues by asset or subtype, or search for an asset by name, profile, or subtype. Filtering is dynamic, with available filters depending on results.

  7. Review finding information:

    • Name: The deployed asset’s name. Select the name to review detailed information for each security issue for that asset.

    • Profile name: The latest commit ID for code assets, or the latest image and version of the deployed binary asset.

    • Type: The asset type, either code or binary.

    • Sub type: The subtype of asset, such as GitHub or Bitbucket repository for code asset types, or CloudBees platform workflow artifact for binary asset types.

    • Last scanned: The last time the asset was scanned.

    • The number of findings, grouped by the severity rating reported by the security tool that discovered the finding.

Security issues

To review detailed security information for an asset, select that asset’s name from the Security center.

Security issues
Figure 2. Security issues
  1. Select an environment configured for the application.

  2. Review the asset profile name, and the type of asset profile.

  3. Review the total number of open findings for the selected asset, the number of findings by severity, the number of findings within or that have breached the SLA, and the date the asset was last scanned.

  4. Review the total number of findings, grouped by security tool. Select a tool’s number of findings to filter findings by that tool.

  5. Search issues, or filter by one or more of:

    • Category:

      • Configuration.

      • License violation.

      • Operational risk.

      • Penetration testing outcome.

      • Policy violation.

      • SCA.

      • Secret violation.

      • Threat modelling outcome.

      • Vulnerability.

    • Risk accepted (RA) findings expiry:

      • Risk accepted findings expiring within a date range.

      • Risk accepted findings expiring by an end date.

    • Severity:

      • Very High.

      • High.

      • Medium.

      • Low.

    • SLA status:

      • Breached SLA.

      • Within SLA.

    • Status (For further information on status, refer to Triage findings):

      • Open.

      • In progress.

      • Resolved.

      • False positive.

      • Risk accepted.

      • Closed.

    • Security tool.

  6. Review the number of findings of each status. Select a status to filter findings by that status. For further information about status, refer to Triage findings.

  7. Review security issue information:

    • Severity: the severity rating reported by the security tool that discovered the finding. Select to review detailed information on each finding of the issue.

    • Code / Name: The vulnerability code, or CVE/CWE number of the issue, and the name of the issue.

    • Category: The category of finding. For example, operational risk, or vulnerability.

    • Findings: The number of findings of that issue type that have been identified by security tools.

    • Tools: The security tools that identified the finding.

    • The date the finding was First identified.

  8. Review detailed information on each finding of the issue, including:

    • File Name: The name of the file where the finding was discovered. For code findings, select the file name to navigate to the GitHub or Bitbucket repository containing the file, and the line in the file where the finding is located.

      For findings discovered by Coverity on Polaris, CloudBees platform redirects to the file containing the issue, but does not highlight the line number, as this is not supported by the Coverity tool itself.

      • Tools: The tool that discovered the finding.

      • Ticket: Any ITSM ticket number associated with the finding.

      • SLA due: The SLA due date. Hover over to review the SLA status, due date, and the date the finding was first reported.

      • Status: The status of the finding.

      • Triage: Select to triage the finding

Triage findings

By default, when a security scan detects an issue, a new finding is created in the security center with its status set to Unreviewed. From here, a user with the Admin role, or a custom role with the triage findings permission, should transition its status to Fix Required, at which point it is moved to the Fix Required tab.

During the triage process, a qualified security or DevOps SME is likely to uncover findings that either fall within your tolerance for risk, or are false positives, neither of which require remediation. In the CloudBees platform, a user with the correct permissions can transition the status of these findings to Risk Accepted if they have decided not to fix the issue, or to False Positive if they believe the security finding is incorrect. Transition all other findings to Fix Required.

Once a finding has been transitioned to Risk Accepted or False Positive, its status won’t be affected by new scans. Resolved findings are automatically updated. Once a developer fixes all the associated findings, the source code management platforms such as GitHub or Bitbucket inform the CloudBees platform, which initiates a new scan. If the scan doesn’t find any violations, the finding is automatically marked as closed in your collaboration tool, and its status updated to Resolved.

To triage findings:

  1. Select an organization.

  2. Select Applications, then select an application.

  3. Select Security center.

  4. Select the asset containing the finding you want to review.

  5. For the issue containing the finding you want to review, select to expand the issue.

  6. Select Triage.

  7. Select one of the following:

    • Fix Required: The finding needs to be fixed.

    • False Positive: The finding is incorrect, or not an actionable issue. Selecting false positive immediately updates the status of the finding, and it appears in dashboards as a false positive finding.

      The user can transition the finding back for further triage. An organization owner can also reject the transition to false positive, which reverts the status to Unreviewed.

      • For Justification, enter comments for the organization owner, explaining why the finding is a false positive.

    • Risk Accepted: the issue falls within your risk tolerance. Transition to risk accepted requires approval by an organization owner.

      • For Expiry date, select a date for the risk acceptance to expire. Defaults to 90 days.

      • For Justification, enter comments for the organization owner, explaining why the finding falls within risk tolerance.

  8. Select Triage Finding:

    • Fix Required findings are moved to the Fix Required tab.

    • False Positive and Risk Accepted findings are moved to the Awaiting Approval tab, to be reviewed by an organization owner.

Approve or deny transitions

Transition requests are approved by users with the Admin role, or another role with the necessary permissions. For further details, refer to Triage permissions.

To approve or deny a transition request:

  1. From the Security Center, select the repository containing the finding, then select the Awaiting Approval tab.

  2. For the issue containing the asset you want to review, select to expand the issue.

  3. Select Review.

  4. Select either:

    • Approved

    • Denied

  5. For approved findings, enter an Expiry Date for the approval.

  6. Enter any review comments.

  7. Select Submit review:

    • Approved transitions change to the relevant status, false positives indefinitely, and risk accepted findings for the selected timeframe (90 days by default).

      For risk accepted findings, the SLA due date is replaced with the risk-acceptance expiry date. Once the expiry date passes and a scan completes, the finding reverts back to unreviewed status, and the SLA due date reverts back to the current SLA setting for the organization.
    • Denied transitions have their status changed:

      • Denied false positives to Unreviewed.

      • Denied risk accepted to Fix required.

Triage permissions

By default, only admins can triage findings, but custom user roles can be created to allow users more granular control of triage.

Custom permissions assigned to a user belonging to an organization’s system generated teams will not work. Instead, you must assign the user to a custom team.

The following user role permissions affect triage:

Table 1. Triage permissions
Role permission Purpose

Review risk accepted request

Review a transition request for a risk accepted finding.

Review false positive request

Review a transition request for a false positive finding.

SLA configuration

Triage findings

Triage security findings: transition a finding to fix required, risk accepted, or false positive.

View findings by triage status

View security findings in the security center, grouped by triage status.

For further details on users, roles, and permissions, refer to Role-based access control.