🎼Static Application Security Testing (SAST)

Summary

Arnica's powerful static code analysis feature allows developers to find and fix coding issues and security vulnerabilities in their code. Arnica leverages Semgrep as the backend engine for its SAST scanning capabilities, and adds proprietary customization and automation features. Key advantages with Arnica's SAST capabilities include, expanded rule libraries and language coverage, configurable automation of scans, and the ability to create custom SAST rules for your specific environment, enabling Arnica operators to tailor the analysis to their unique project requirements, coding standards, and security concerns.

Supported languages

The following languages are supported:

Supported	Beta Support	Experimental
C	Swift	Bash
C++		Cairo
C# (.net)		Clojure
Go		Dart
Java		Elixir
JavaScript (including JSX, TSX and TypeScript)		HTML
Kotlin		Jsonnet
PHP		Julia
Python		Lisp
Ruby		Lua
Rust		OCaml
Scala		R
		Scheme
		Solidity

Support Definitions

Support Level	Definition
Supported	99%+ parse rate and 10+ rules.
Beta Support	95%+ parse rate and 5+ rules.
Experimental	90%+ parse rate and at least one rule.

Global rules

Arnica security research team maintains a rich library of SAST rules which are leveraged within Arnica's SAST scanning. Combined with Semgrep's open source libraries, Arnica's global rules ensure expanded language support and additional security coverage. These rules are derived from customer input, community engagement, and Arnica's security research team, and are continuously improved. By researching enables customers to run their own SAST rules to identify specific risks across the company with minimal changes. This enables customers to override default SAST rules to improve accuracy, change description or risk severity.

Arnica uses the open source rules maintained by Semgrep and then cleans up all rules that were identified to be less valuable, such as code correctness rules, deprecated rules, or other specific rules.

Custom SAST Rules

Arnica enables users to create, manage, and edit custom SAST rules directly within the solution. See more information on Custom SAST Rules here.

Reviewing SAST findings

To view all SAST findings, navigate to the code risks page.

Select the Type column header and filter only SAST findings.

SAST findings filter

All findings have both basic and expanded information. The basic information can be reviewed in the columns of each finding in the global table. To see the expanded detail of each finding, click on the relevant row. An expended card will appear at the bottom of the screen.

Expanded finding view

Details

Commit information

The top section within Details contains information from the commit and the Git push event. The first tile includes the commit message, a link to the original commit, and the relative time of the commit timestamp to now.

If the event was captured as part of a git push, the pusher will be shown. Otherwise, the field will be unknown. The author of the commit will be resolved as well.

If the pusher or author is no longer a member of your Git organization, an alert will appear in red next to the name.

Description

The description will include more information about the vulnerability and show the relevant code that is impacted by this vulnerability.

The Rule ID identifies the specific rule that flagged the code risk. This ID can be used when overriding an existing rule within Arnica. This can be done in Arnica's custom SAST rule builder.

Categorization

Rules are typically tagged with the applicable CWE and OWASP categories.

References

Relevant references are added to the findings. If the rule originates from Semgrep's open-source rules library a link to the rule definition within Semgrep's registry is included in this section.

Remediation owners

Arnica's unique behavioral models identify and list the names of individuals that are best equipped to help resolve each finding. For example, a user may be listed if they are a frequent pull request reviewer. For more information, see the Prioritization & Product Ownership page.

History

Each finding has a full history of all events that occurred as part of its lifecycle. The history is comprised of many different events, such as:

• Feature branches where the vulnerability is introduced or resolved.

• Notifications or developer actions through Arnica's Slack or Microsoft Teams integration

• Links to comments in pull requests

• Links to status checks and the reports Arnica generated in each status check run

• SLA timer indications

• Changes to the risk's status

• If a review is required to approve a finding dismissal, it will be indicated.