Skip to content

Writing Rules

Gabe Stocco edited this page Jan 31, 2024 · 27 revisions

DevSkim's detection logic is based on regular expressions (using JavaScript/C# RegEx syntax) and can trigger additional patterns for further refinement after an initial match. Writing rules for a language not currently supported is possible.

Basic Rule Anatomy

Rules files are written in JSON. They consist of a high level rule object containing an array of pattern objects, which define regular expressions used for an initial match.

Patterns may also define an array of condition objects with additional patterns that must all be satisifed to verify a finding.

Lastly, patterns may define fix_its which contain logic to convert vulnerable code into safe code.

Advanced Rule Features

Additional Authoring Documentation

Additional rule authoring documentation is available in the Application Inspector wiki. The format used is nearly identical other than additional DevSkim features like fixes.

Default Rules

The built in rules that are published with DevSkim can be found in the DevSkim repository.

Sample Rule

See Sample Rule for a detailed rule sample.

Severity Levels

DevSkim supports the following severity levels in rule configuration.

  • Critical - Indicates a high risk security issue that should be highly prioritized
  • Important - Indicates a medium risk security issue that should be prioritized
  • Moderate - Indicates a lower risk security issue
  • BestPractice - Indicates a code hygiene issue or coding practice that can be improved but is not necessarily a security issue
  • ManualReview - Indicates an issue that cannot be deterministically determined by DevSkim to be actionable or not. Requires the DevSkim user or an analyst reviewing the results to review if the finding applies in the particular case identified.
  • Unspecified - If the severity is not specified properly on the rule object specification, findings for that rule will be reported as Unspecified. This should not be the case for any default rules that ship with DevSkim. If you encounter such a finding from a built-in rule, please report it as a rule related bug.

Sarif Severity Levels

The Sarif format uses a different set of severity levels. These are calculated from the DevSkim severity for an issue as follows:

DevSkim Level Sarif Level
Critical Error
Important Error
Moderate Warning
BestPractice Note
ManualReview Note
Unspecified None

In addition, the original DevSkim severity level is included in the properties object for each result in the sarif output.

Reference