On our platform, you can set various policies for acceptance of vulnerabilities and members access control in your organization to help you control the risks you are willing to take in your groups. You can access the Policies section by clicking on the Policies tab on your organization's home page on our platform.
In this section, you will find two tables. The first one allows you to define values for seven policies within your organization. The first four policies specify the conditions for the temporary acceptance of vulnerabilities; the next two, for breaking the build; and the last one, for defining an inactivity period for the platform usage. Below we explain each of the seven policies you can set up. You can hover your cursor over the icon with the letter i next to a policy to see the value we recommend.
Maximum number of calendar days a finding can be temporarily accepted
Here you define the maximum number of calendar days that a finding can be temporarily accepted; this limit can be at most 31 calendar days. This policy affects the execution of the DevSecOps agent in case you are using it, since temporarily accepted vulnerabilities will not be considered at the time of breaking your build. This means that you have to be careful when setting this number to prevent some vulnerabilities remaining unresolved for a long time, which increases the risk to your applications.
Maximum number of times a finding can be accepted
Here you define the maximum number of times that a vulnerability can be temporarily accepted. If, for example, you set this number as one and accept a vulnerability temporarily, after the acceptance period passes, or you change the treatment of that vulnerability or remediate it, you won't be able to accept that same vulnerability again in the future. This number can be any number you deem appropriate.
Grace period where newly reported vulnerabilities won't break the build
Period in days (DevSecOps only). Here you define the period in days that you allow a vulnerability to be open without it causing the DevSecOps agent to break the build.
Minimum CVSS 3.1 score of an open vulnerability for DevSecOps
Score to break the build in strict mode. Here you define the minimum value of the CVSS score that a vulnerability has to have in order for the DevSecOps agent to break the build.
Temporary acceptance: minimum CVSS 3.1 score allowed for assignment
Here you define the minimum range in severity score, according to CVSS 3.1 (values from 0.0 to 10.0), within which you want vulnerabilities to be temporarily accepted.
Temporary acceptance: maximum CVSS 3.1 score allowed for assignment
Here you define the maximum range in severity score, according to CVSS 3.1 (values from 0.0 to 10.0), within which you want vulnerabilities to be temporarily accepted. This means that you can control the maximum risk you are willing to take.
Login inactivity: number of days for members inactivity period
Here you define the number of days of allowed inactivity before a member is removed if there are no logins to the platform. The given member is removed completely and all the granted access to organizations and groups will be revoked. In case the user wants to access those resources again, once the removal due to inactivity has been performed, they have to request a new invitation to the organization or group manager.
In the second table, you will find a list of the types of vulnerabilities that your team has suggested for permanent acceptance. In front of each vulnerability type name, you will see whether that acceptance was approved, rejected or is pending. All those vulnerability types listed there as accepted will be ignored by our DevSecOps agent in its task of breaking the build. Therefore, you assume the risk that comes with their being allowed into production.
In this section, you can add all vulnerability typologies reported in an organization or individually select those that you want to apply the Temporarily Accepted treatment, having an approval process before applying such treatment. When specific rules are not defined in this policy (default behavior), requests for temporary approvals are automatically approved without requiring additional validations.
Below, we will explain how to apply this approval system.
As mentioned above, you can apply to all vulnerabilities reported in the organization by clicking on the Vulnerability type field in the All Vulnerabilities Types option.
Note: Setting this option will apply the approval request to all reported typologies.
If you prefer to apply this setting individually, select the typology for which you would like to request temporary treatment approval.
Note: Remember that you can add tags.
Now, when you have selected the typology, you can click on the plus symbol. The request for approval of this typology will be sent, and it will be in a submitted status, which a *manager role can approve or not.
Once approved, the status will change to 'Approved'. After that, when applying the 'Temporarily Accepted' treatment, approval will be required prior to application.
Add a vulnerability type
To add a Vulnerability type, you have to type its name in the bar, and if you want, you can add tags. After that, you can click on the plus symbol.
After this the vulnerability type will go to Submitted status. Remember that any team member can make the approval request. On the other hand, you can approve or reject only if you are either an User Manager or a Vulnerability Manager.
Approve and reject
You can accept a type of vulnerability by clicking the check mark button, which will change its status from submitted to approved. Conversely, by clicking the cross-mark button, the status will change to rejected.
Disable and Re-submit
You can also disable the acceptance policy for a type of vulnerability by clicking the button with the circle cross sign.
A pop-up window will appear asking for confirmation. By clicking on Confirm, this vulnerability’s status will automatically change to inactive.
There’s another button that has a right arrow symbol. This button is available when the status of the type of vulnerability is inactive.
Clicking it will change the status to submitted, and you can further decide whether or not the vulnerability will be accepted.
In the Policies section of your organization, you can find a table under the title Permanent acceptance. There you can add types of vulnerabilities to accept them permanently. When doing that, you can also add one or more tags under which you would like to classify the type of vulnerability. After clicking the add button, the tag(s) you chose will be applied automatically to all the vulnerabilities of that type.