A common use case for using a custom Policy is to provide application- or organization-specific rules that more accurately reflect the state of sensitive data variables. This article illustrates how to create just such a custom Policy for an application-specific sensitive-data dictionary, using an example the
The process is:
For additional information, refer to the articles:
Create the new Policy file with the
no-dictionary template, using the following command
sl policy create no-dictionary my-app-dictionary.policy
my-app-dictionary.policy is the location and name of the new Policy file.
The command creates the new Policy file and imports default definitions, as declared by ShiftLeft, except for the sensitive-data dictionary.
Develop your application-specific dictionary by editing the
my-app-dictionary.policy file with your own unique sensitive-data directives.
As defined in the ShiftLeft Policy Language, sensitive-data directives have the form
DATA $group = VAR $term1, ..., $term_n
$group is a sensitive-data group such as "internal-secrets"
$term1 to $termn are keywords.
The default Policy contains this directive to characterize highly sensitive data
DATA highly-sensitive = VAR master key, cvv num, cvv, cvc num, cvc, encrypt key, crypt key
The sensitive-data engine looks for exact matches, as well as variations and combinations, of these terms.
For example, you are only interested in a limited number of data-sensitive categories to define Personal Identifying Information that includes email, phone number and (people) names. And you want to ignore any other categories. To get that information, append the following sample snippet to the
# PIIDATA pii = VAR first name, last name, middle name, middle initials, full name, maiden name, player name, family nameDATA pii = VAR email, email addr, email address, alternate emailDATA pii = VAR phone number, phone, mobile, landline number, home phone number, home phone num, office phone number, office phone num, alternate phone num, alternate phone number, phone number extension
So that the Policy directive is
IMPORT io.shiftleft/default# PIIDATA pii = VAR first name, last name, middle name, middle initials, full name, maiden name, player name, family nameDATA pii = VAR email, email addr, email address, alternate emailDATA pii = VAR phone number, phone, mobile, landline number, home phone number, home phone num, office phone number, office phone num, alternate phone num, alternate phone number, phone number extension
Verify that your new Policy is valid by running
sl policy validate my-app-dictionary.policy
This command returns a non-zero exit status code if there is a problem in either syntax and/or semantics of the new Policy.
Upload your custom Policy with the command
sl policy push myNewDictionary my-app-dictionary.policy
If successful, the command returns the full name under which the Policy is available, eg.,
ebad68cf-b1bf-4b00-b524-8d41c6b4ff7e represents the organization ID from which the Policy was submitted.
latest is the tag assigned to the Policy (added by default).
To assign the new Policy to your application, when using ShiftLeft Inspect run the command
sl analyze --policy ebad68cf-b1bf-4b00-b524-8d41c6b4ff7e/myNewDictionary --app my-application ~/path/to/file.jar
As expected, using your custom Policy, ShiftLeft Inspect identifies less vulnerabilities for your application than if using the default Policy. This is because the dictionary of sensitive-data categories in the custom Policy has been significantly reduced.