DevSkim Security Analysis Framework

DevSkim is a framework of IDE extensions and language analyzers providing inline security analysis during development.

Key Features:

• Built-in rules and support for custom rules (using JSONPath, XPATH, and YmlPath).
• Cross-platform CLI for file analysis.
• IDE plugins for Visual Studio and VS Code via Language Server Protocol.
• IntelliSense error squiggles and guidance for security issues.
• Optional suppression of findings.

Supported Languages include:

• C, C++, C#, Cobol, Go, Java, Javascript/Typescript, Python, and more.

DevSkim is a framework consisting of IDE extensions and language analyzers designed to provide inline security analysis directly within the development environment. It identifies security vulnerabilities as code is being written, providing real-time feedback to help developers fix issues at the point of introduction.

Key features include:

• Built-in and Custom Rules: Supports a flexible rule model for multiple programming languages.
• IntelliSense Integration: Uses standard error "squiggly lines" to flag security issues.
• Actionable Guidance: Provides descriptions, remediation steps, and links to further information via mouseover.
• Automated Fixes: Offers safe alternatives through the IDE lightbulb menu for certain issues.
• Broad Language Support: Includes C, C++, C#, Cobol, Go, Java, Javascript/Typescript, Python, and more.

Using an initialization vector that is shorter than the expected size, or reusing initialization vectors, can compromise data security. This is particularly dangerous when using streaming cipher modes such as:

• Output Feedback (OFB)
• Counter (CTR)

In these modes, improper IV handling may reveal information about the encrypted data.

DevSkim uses a language-agnostic approach, primarily identifying issues via regular expressions. This allows for easy custom rule creation for almost any programming language.

Supported Languages include:

• C, C++, C#, Cobol, Go, Java, Javascript/Typescript, Python, and more.

Rule Capabilities:

• Built-in rules for dangerous crypto usage across most languages.
• Language-specific security rules.
• Support for writing custom rules (see Writing Rules for details).

DevSkim uses a language-agnostic approach to security analysis. It primarily identifies issues using regular expressions, making it possible to write rules for almost any programming language.

• Built-in Rules: Includes rules for dangerous cryptography usage across most languages and various language-specific security issues.
• Custom Rules: Users can write their own rules to extend the analyzer's capabilities. For detailed instructions, refer to the Writing Rules documentation.

When evaluating the severity of an SSL/TLS configuration finding, increase the severity level if:

• The underlying security context is highly sensitive.
• The network environment has low trust.

DevSkim identifies the use of hard-coded cryptographic algorithms and parameters as a security risk (Rule DS440001). Hard-coding these values reduces crypto agility—the ability of an application to migrate from one cryptographic algorithm to another (e.g., moving from AES-128 to AES-256) or to switch parameters when new vulnerabilities are discovered or stronger algorithms become available.

To maintain security and flexibility, avoid hard-coding specific algorithms or parameters directly in your source code. Instead, design your application to allow for easier updates to cryptographic configurations.

You can suppress DevSkim warnings using the lightbulb menu. DevSkim supports two types of suppressions:

1. Permanent Suppressions: Used when the flagged code should not be changed.
2. Timed Suppressions: Used when the code should be changed eventually, but not immediately. The default period is 30 days, but this can be adjusted in the settings file.

When a suppression is applied, DevSkim inserts a comment after the code containing the specific issue number (e.g., DS181021) and the suppression details. This allows other contributors to understand why the issue is being ignored. You can also add custom comments after the suppression to provide additional context.

DevSkim has detected the use of the strlen function, which can lead to buffer overrun vulnerabilities if a string is missing a null terminator. To remediate this, replace strlen with a secure version that allows specifying a maximum length to check.

Recommended Solutions

• Use strnlen to limit the number of characters scanned.
• Use strlen_s (if using the Microsoft C Runtime) to provide a safer alternative.

Severity

Buffer overruns can potentially allow an attacker to execute arbitrary code, leading to complete system compromise.