Files that changed from the base of the PR and between 1521a46 and 650b88b.

• rules/c/security/sizeof-this-c.yml (1 hunks)
• rules/html/security/plaintext-http-link-html.yml (1 hunks)
• rules/java/security/cbc-padding-oracle-java.yml (1 hunks)
• rules/java/security/desede-is-deprecated-java.yml (1 hunks)
• rules/java/security/no-null-cipher-java.yml (1 hunks)
• rules/java/security/rsa-no-padding-java.yml (1 hunks)
• rules/kotlin/security/desede-is-deprecated-kotlin.yml (1 hunks)
• rules/scala/security/rsa-padding-set-scala.yml (1 hunks)
• rules/scala/security/xmlinputfactory-dtd-enabled-scala.yml (1 hunks)
• rules/swift/security/insecure-biometrics-swift.yml (1 hunks)
• tests/snapshots/cbc-padding-oracle-java-snapshot.yml (1 hunks)
• tests/snapshots/desede-is-deprecated-java-snapshot.yml (1 hunks)
• tests/snapshots/desede-is-deprecated-kotlin-snapshot.yml (1 hunks)
• tests/snapshots/insecure-biometrics-swift-snapshot.yml (1 hunks)
• tests/snapshots/no-null-cipher-java-snapshot.yml (1 hunks)
• tests/snapshots/plaintext-http-link-html-snapshot.yml (1 hunks)
• tests/snapshots/rsa-no-padding-java-snapshot.yml (1 hunks)
• tests/snapshots/rsa-padding-set-scala-snapshot.yml (1 hunks)
• tests/snapshots/sizeof-this-c-snapshot.yml (1 hunks)
• tests/snapshots/xmlinputfactory-dtd-enabled-scala-snapshot.yml (1 hunks)
• tests/c/sizeof-this-c-test.yml (1 hunks)
• tests/html/plaintext-http-link-html-test.yml (1 hunks)
• tests/java/cbc-padding-oracle-java-test.yml (1 hunks)
• tests/java/desede-is-deprecated-java-test.yml (1 hunks)
• tests/java/no-null-cipher-java-test.yml (1 hunks)
• tests/java/rsa-no-padding-java-test.yml (1 hunks)
• tests/kotlin/desede-is-deprecated-kotlin-test.yml (1 hunks)
• tests/scala/rsa-padding-set-scala-test.yml (1 hunks)
• tests/scala/xmlinputfactory-dtd-enabled-scala-test.yml (1 hunks)
• tests/swift/insecure-biometrics-swift-test.yml (1 hunks)

• tests/snapshots/cbc-padding-oracle-java-snapshot.yml
• tests/snapshots/desede-is-deprecated-java-snapshot.yml
• tests/snapshots/desede-is-deprecated-kotlin-snapshot.yml
• tests/snapshots/insecure-biometrics-swift-snapshot.yml
• tests/snapshots/no-null-cipher-java-snapshot.yml
• tests/snapshots/plaintext-http-link-html-snapshot.yml
• tests/snapshots/rsa-no-padding-java-snapshot.yml
• tests/snapshots/rsa-padding-set-scala-snapshot.yml
• tests/snapshots/sizeof-this-c-snapshot.yml
• tests/swift/insecure-biometrics-swift-test.yml

tests/c/sizeof-this-c-test.yml (1)

1-7: Verify the use of this in C context.

The test cases use this, which is typically associated with C++. Please confirm that the context of this in these test cases is appropriate for C, or if it should be adjusted to reflect typical C usage.

tests/java/cbc-padding-oracle-java-test.yml (1)

1-7: Well-defined test cases for CBC padding oracle vulnerabilities.

The test cases are clearly defined, with appropriate examples for valid and invalid configurations:

• The valid test case uses "AES/GCM/NoPadding" which is secure and not vulnerable to padding oracle attacks.
• The invalid test case uses "AES/CBC/PKCS5Padding" which is susceptible to padding oracle attacks.

This setup correctly reflects the rule's intent to detect vulnerabilities related to CBC padding oracle attacks.

Tools

yamllint

[error] 7-7: no new line character at the end of file

(new-line-at-end-of-file)

tests/java/no-null-cipher-java-test.yml (1)

1-8: Header and Test Case Structure Approved

The file header and test case structure are correctly set up for the "no-null-cipher-java" rule. This setup effectively distinguishes between valid and invalid test cases, which is crucial for clarity and maintainability.

Tools

yamllint

[error] 8-8: no new line character at the end of file

(new-line-at-end-of-file)

tests/java/desede-is-deprecated-java-test.yml (1)

1-8: Review of the test configuration for desede-is-deprecated-java

• ID and Structure: The file is well-structured with clear separation between valid and invalid examples. The ID is appropriately named to reflect the rule it tests.
• Valid Example: The example using Cipher.getInstance("AES/GCM/NoPadding"); is correctly placed under valid examples, as AES/GCM is a secure and recommended encryption method.
• Invalid Examples: The examples using Cipher.getInstance("DESede/ECB/PKCS5Padding"); and javax.crypto.KeyGenerator.getInstance("DES") are correctly placed under invalid examples. DESede is deprecated, and DES is not secure, making both examples suitable for demonstrating what the rule should catch.

Overall, the test configurations are correctly set up to validate the rule's effectiveness in identifying uses of deprecated and insecure cryptographic methods.

tests/java/rsa-no-padding-java-test.yml (3)

1-1: File ID is correctly set.

The id field correctly identifies the test configuration for the Java rule rsa-no-padding-java.

---

3-5: Valid test case is appropriate.

The valid test case correctly uses a secure padding scheme (OAEPWithMD5AndMGF1Padding) which is a good practice for RSA encryption.

---

6-8: Invalid test cases are well-defined.

The invalid test cases correctly identify insecure configurations (NoPadding) which should indeed be flagged by the rule.

Tools

yamllint

[error] 8-8: no new line character at the end of file

(new-line-at-end-of-file)

tests/kotlin/desede-is-deprecated-kotlin-test.yml (1)

1-8: Well-structured test cases for the Kotlin rule.

The test cases are well-structured and clearly differentiate between valid and invalid scenarios:

• The valid case uses AES/GCM/NoPadding, which is a secure and recommended practice, contrasting well with the deprecated practices.
• The invalid cases effectively highlight the use of deprecated DESede/ECB/PKCS5Padding and the associated key generation for DES, aligning perfectly with the rule's intent to flag deprecated cryptographic methods.

Overall, the test configurations are appropriate and should effectively validate the rule's implementation.

tests/scala/rsa-padding-set-scala-test.yml (2)

3-6: Valid test cases are well-defined.

The inclusion of non-RSA algorithms in the valid section helps ensure that the rule accurately identifies only the intended RSA padding issues.

---

9-9: Invalid test case is correctly identified.

The test case for RSA/ECB/NoPadding is appropriately marked as invalid, aligning with the rule's objective to flag insecure RSA configurations.

Tools

yamllint

[error] 9-9: no new line character at the end of file

(new-line-at-end-of-file)

tests/__snapshots__/xmlinputfactory-dtd-enabled-scala-snapshot.yml (2)

1-1: Verify the ID format.

Ensure that the ID xmlinputfactory-dtd-enabled-scala follows the naming conventions and standards used in the project for snapshot IDs.

---

8-11: Review label configuration.

The labels are configured to highlight the source code snippet:

XMLInputFactory.newFactory()

Ensure that the start and end positions (14 and 42) accurately reflect the positions in the source code. This is crucial for the correct functioning of the snapshot testing.

rules/java/security/rsa-no-padding-java.yml (2)

1-10: Metadata and rule definition are well-formed.

The rule ID, severity, language, message, and note are correctly defined and provide clear, useful information.

---

11-11: Clarify the placeholder $YST.

The pattern uses $YST.getInstance($MODE) which seems to be a placeholder. If this is intended to be generic, consider specifying this in the documentation or comments to avoid confusion.

rules/c/security/sizeof-this-c.yml (6)

1-1: Rule ID is well-defined.

The ID sizeof-this-c is appropriately named, reflecting the specific security concern it addresses.

---

2-2: Correct language specification.

The language is correctly set to c, targeting C programming language files.

---

3-3: Appropriate severity level.

The severity level is set to warning, which is suitable given that the misuse of sizeof(this) could lead to incorrect memory size calculations but typically does not directly result in a security vulnerability.

---

4-6: Clear and informative message.

The message clearly explains the issue with using sizeof(this) in C, noting that it returns the size of the pointer rather than the object itself, which is a common mistake.

---

7-10: Detailed note with external reference.

The note provides a CWE reference and a link to an external resource that offers more in-depth information, which is helpful for developers looking to understand or mitigate the issue.

---

11-13: Accurate rule pattern.

The rule pattern sizeof(this) is accurately targeted to catch the specific misuse of the sizeof operator on the this pointer in C code.

tests/html/plaintext-http-link-html-test.yml (1)

1-15: Comprehensive Test Coverage for plaintext-http-link-html Rule

The test file is well-structured and covers a broad range of cases for both valid and invalid scenarios:

• Valid Cases (Lines 3-6): These cases correctly identify secure links or non-HTTP links as valid. This includes HTTPS links and a JavaScript protocol, which should not trigger the rule.
• Invalid Cases (Lines 8-15): These cases effectively capture various instances of plaintext HTTP links, including different HTML attribute formats and case insensitivity. This ensures the rule is robust against common variations in HTML link usage.

Suggestions:

• Case Sensitivity (Line 15): The inclusion of a case-insensitive HTTP link is excellent. It tests the rule's ability to catch HTTP links regardless of case variations.
• Attribute Variations (Lines 11, 14): Testing links without quotes and with different attribute arrangements is crucial, as it ensures the rule can handle less conventional HTML syntax.

Overall, the test configurations are thorough and appear to be well-suited for ensuring the rule behaves as expected across a variety of HTML link scenarios.

rules/java/security/desede-is-deprecated-java.yml (1)

1-13: Metadata and rule configuration review.

The metadata fields including id, language, severity, message, and note are well-defined and provide clear information about the rule's purpose and its importance. The links in the notes section are relevant and provide additional context for why DESede is deprecated.

• The id is unique and descriptive.
• The language field correctly specifies Java.
• The severity level as warning is appropriate given the nature of the deprecation.
• The message clearly explains the issue and suggests an alternative.
• The note section effectively uses references to enhance the rule's credibility and informational value.

rules/kotlin/security/desede-is-deprecated-kotlin.yml (5)

1-2: Confirm rule ID and language settings.

The rule ID and language are set to desede-is-deprecated-kotlin and kotlin respectively, which are appropriate for the intended purpose. Ensure that the rule ID is unique within the repository.

---

4-5: Review the message for clarity and actionability.

The message clearly states that Triple DES (DESede) is deprecated and recommends upgrading to AES. This is actionable and informative.

---

6-9: Check the relevance and accuracy of notes.

The notes reference CWE and OWASP categories related to encryption and data exposure, which are relevant to the rule. Ensure these references are up-to-date and accurately reflect the rule's intent.

---

10-12: Validate external references.

The provided links are intended to support the rule's rationale. Verify that these links are accessible and contain relevant information about the deprecation of DESede.

Run the following script to check the accessibility of the URLs:

---

13-16: Assess the rule patterns for accuracy and specificity.

The patterns are designed to catch instances of DESede usage in Kotlin code. The first pattern looks for any instance of DESede in the getInstance method, which is a common usage pattern. The second pattern targets the KeyGenerator instance for DES. Ensure these patterns do not result in false positives by being overly broad.

Run the following script to test the patterns against a sample codebase:

rules/swift/security/insecure-biometrics-swift.yml (4)

1-2: Rule ID and Language Specification

The rule ID insecure-biometrics-swift and the language specification swift are correctly defined. This ensures that the rule is correctly categorized and will be applied to Swift codebases.

---

3-3: Severity Level

The severity level is set to info. Considering the nature of the vulnerability, which primarily affects jailbroken devices, this severity might be appropriate. However, it could be argued that a higher severity might be warranted given the potential security implications of bypassing biometric authentication.

Consider revisiting the severity level based on the potential impact of the vulnerability in production environments.

---

4-10: Message Clarity and Detail

The message provided gives a clear and detailed explanation of the vulnerability, including the methods by which biometric authentication can be bypassed and a recommendation for a more secure implementation using Keychain Services. This is well-documented and provides actionable advice.

---

11-15: Note and References

The note includes a CWE reference which is appropriate for the type of vulnerability. The references provided are relevant and useful for further reading. This enhances the rule's utility by providing additional context and resources.

Files that changed from the base of the PR and between 650b88b and b0c6e4e.

• rules/html/security/plaintext-http-link-html.yml (1 hunks)
• rules/java/security/cbc-padding-oracle-java.yml (1 hunks)
• rules/java/security/no-null-cipher-java.yml (1 hunks)
• rules/java/security/rsa-no-padding-java.yml (1 hunks)
• rules/scala/security/rsa-padding-set-scala.yml (1 hunks)
• rules/swift/security/insecure-biometrics-swift.yml (1 hunks)

• rules/java/security/cbc-padding-oracle-java.yml
• rules/scala/security/rsa-padding-set-scala.yml

• rules/html/security/plaintext-http-link-html.yml
• rules/java/security/no-null-cipher-java.yml
• rules/java/security/rsa-no-padding-java.yml

Files that changed from the base of the PR and between b0c6e4e and 30f9ae3.

• rules/c/security/libxml2-audit-parser-c.yml (1 hunks)
• rules/cpp/security/libxml2-audit-parser-cpp.yml (1 hunks)
• rules/csharp/security/httponly-false-csharp.yml (1 hunks)
• rules/rust/security/reqwest-accept-invalid-rust.yml (1 hunks)
• tests/snapshots/httponly-false-csharp-snapshot.yml (1 hunks)
• tests/snapshots/libxml2-audit-parser-c-snapshot.yml (1 hunks)
• tests/snapshots/libxml2-audit-parser-cpp-snapshot.yml (1 hunks)
• tests/snapshots/reqwest-accept-invalid-rust-snapshot.yml (1 hunks)
• tests/c/libxml2-audit-parser-c-test.yml (1 hunks)
• tests/cpp/libxml2-audit-parser-cpp-test.yml (1 hunks)
• tests/csharp/httponly-false-csharp-test.yml (1 hunks)
• tests/rust/reqwest-accept-invalid-rust-test.yml (1 hunks)

• tests/snapshots/httponly-false-csharp-snapshot.yml
• tests/snapshots/libxml2-audit-parser-c-snapshot.yml
• tests/snapshots/libxml2-audit-parser-cpp-snapshot.yml

tests/c/libxml2-audit-parser-c-test.yml (2)

3-4: Valid example approved.

The use of xmlCtxtReadMemory() is considered safe and appropriate for demonstrating valid usage in this context.

---

6-8: Invalid example approved.

The use of xmlParseInNodeContext with direct string and length parameters, as well as pointer manipulation, is appropriately flagged as unsafe. This example effectively demonstrates potential vulnerabilities in XML parsing.

tests/cpp/libxml2-audit-parser-cpp-test.yml (2)

3-4: Valid example approved.

The use of xmlCtxtReadMemory() is considered safe and appropriate for demonstrating valid usage in this context.

---

6-8: Invalid example approved.

The use of xmlParseInNodeContext with direct string and length parameters, as well as pointer manipulation, is appropriately flagged as unsafe. This example effectively demonstrates potential vulnerabilities in XML parsing.

tests/csharp/httponly-false-csharp-test.yml (2)

3-6: Valid examples approved.

Setting HttpOnly to true is correctly demonstrated as a secure practice for cookie settings in these examples.

---

8-11: Invalid examples approved.

Setting HttpOnly to false is correctly flagged as insecure, demonstrating a potential security risk by exposing cookies to client-side scripts.

tests/rust/reqwest-accept-invalid-rust-test.yml (1)

1-13: Well-defined test cases for TLS configuration rules.

The test cases are appropriately categorized into valid and invalid scenarios, accurately reflecting the rule's intent to identify insecure TLS configurations. Consider adding more complex scenarios if applicable to further validate the rule's effectiveness.

rules/rust/security/reqwest-accept-invalid-rust.yml (1)

1-17: Comprehensive and well-structured rule definition.

The rule is clearly defined with appropriate severity, informative message, and detailed notes. The patterns are well-specified to match insecure TLS configurations. Ensure that the effectiveness of these patterns is verified through comprehensive testing.

tests/__snapshots__/reqwest-accept-invalid-rust-snapshot.yml (1)

1-30: Well-defined snapshot tests for TLS configuration detection.

The snapshot tests are comprehensive and accurately defined with clear labels and positions. These tests should effectively validate the detection capabilities of the rule. Consider continuously updating the snapshots as the rule evolves to ensure ongoing accuracy.

rules/c/security/libxml2-audit-parser-c.yml (1)

14-25: Rule patterns are comprehensive and well-formed.

The patterns effectively cover a wide range of libxml2 parsing functions, ensuring that the rule can catch various potentially unsafe configurations.

rules/cpp/security/libxml2-audit-parser-cpp.yml (1)

14-25: Rule patterns are comprehensive and well-formed.

The patterns effectively cover a wide range of libxml2 parsing functions, ensuring that the rule can catch various potentially unsafe configurations.

rules/csharp/security/httponly-false-csharp.yml (1)

23-25: Rule patterns are comprehensive and well-formed.

The patterns effectively cover typical cookie configurations in C#, ensuring that the rule can catch instances where the HttpOnly flag is disabled.

Files that changed from the base of the PR and between 30f9ae3 and 081bad0.

• rules/csharp/security/oracleconnectionstringbuilder-hardcoded-secret-csharp.yml (1 hunks)
• rules/java/security/ecb-cipher-java.yml (1 hunks)
• tests/snapshots/ecb-cipher-java-snapshot.yml (1 hunks)
• tests/snapshots/oracleconnectionstringbuilder-hardcoded-secret-csharp-snapshot.yml (1 hunks)
• tests/csharp/oracleconnectionstringbuilder-hardcoded-secret-csharp-test.yml (1 hunks)
• tests/java/ecb-cipher-java-test.yml (1 hunks)

• tests/snapshots/ecb-cipher-java-snapshot.yml
• tests/snapshots/oracleconnectionstringbuilder-hardcoded-secret-csharp-snapshot.yml

tests/java/ecb-cipher-java-test.yml (2)

3-4: Approved: Secure Cipher Usage

The example correctly demonstrates a secure usage of the Cipher class using AES/GCM/NoPadding, which is a recommended secure mode of operation.

---

6-7: Approved: Correctly Identified Insecure Cipher Usage

The example correctly identifies an insecure usage of the Cipher class using AES/ECB/NoPadding, which is known for its vulnerabilities and is appropriately marked as invalid.

tests/csharp/oracleconnectionstringbuilder-hardcoded-secret-csharp-test.yml (2)

3-10: Approved: Secure Password Handling

The examples correctly demonstrate secure practices by using dynamic password assignment, which helps prevent security risks associated with hardcoded secrets.

---

11-19: Approved: Correctly Identified Security Vulnerability

The examples correctly identify common security vulnerabilities associated with hardcoded secrets, which are appropriately marked as invalid.

rules/java/security/ecb-cipher-java.yml (1)

1-17: Approved: Well-Defined Security Rule

The rule is well-defined and accurately identifies the use of ECB mode as a security risk. The detailed message and references enhance understanding and provide valuable guidance.

Files that changed from the base of the PR and between bec0b7e and a85cbfb.

• rules/java/security/unencrypted-socket-java.yml (1 hunks)
• rules/java/security/use-of-weak-rsa-key-java.yml (1 hunks)
• rules/kotlin/security/use-of-weak-rsa-key-kotlin.yml (1 hunks)
• tests/snapshots/unencrypted-socket-java-snapshot.yml (1 hunks)
• tests/snapshots/use-of-weak-rsa-key-java-snapshot.yml (1 hunks)
• tests/snapshots/use-of-weak-rsa-key-kotlin-snapshot.yml (1 hunks)
• tests/java/unencrypted-socket-java-test.yml (1 hunks)
• tests/java/use-of-weak-rsa-key-java-test.yml (1 hunks)
• tests/kotlin/use-of-weak-rsa-key-kotlin-test.yml (1 hunks)

• tests/snapshots/unencrypted-socket-java-snapshot.yml

tests/kotlin/use-of-weak-rsa-key-kotlin-test.yml (1)

1-9: LGTM!

The test configuration file is well-structured and includes appropriate valid and invalid code patterns to test the use-of-weak-rsa-key-kotlin security rule.

• The valid code pattern correctly initializes the RSA key pair generator with a secure key size of 2048 bits.
• The invalid code pattern attempts to initialize the key pair generator with an invalid negative floating-point value, which is expected to trigger the security rule.

The file adheres to the YAML format and aligns with the purpose of defining test cases for the security rule.

tests/__snapshots__/use-of-weak-rsa-key-kotlin-snapshot.yml (1)

1-10: LGTM!

The snapshot test configuration file is well-structured and accurately captures the expected output for the invalid code pattern of the use-of-weak-rsa-key-kotlin security rule.

• The snapshot includes the relevant code snippet that triggers the security rule.
• The label details are correctly specified, including the source of the issue, the style as "primary", and the precise start and end positions of the problematic code.

The file adheres to the YAML format and aligns with the purpose of defining snapshot tests for the security rule.

rules/java/security/unencrypted-socket-java.yml (1)

1-16: LGTM!

The Java security rule configuration file is well-structured and effectively addresses the security risk associated with using unencrypted sockets.

• The rule is appropriately named unencrypted-socket-java to reflect its purpose.
• The severity level is set to "info", which is suitable for informational purposes and raising awareness about the security issue.
• The message provides a clear explanation of the security risk and suggests using SSLSocket created by SSLSocketFactory or SSLServerSocketFactory as a secure alternative.
• The note includes relevant information, such as the CWE identifier for cleartext transmission of sensitive information and an OWASP reference for further guidance.
• The rule patterns accurately identify the use of ServerSocket and Socket constructors, which are the target of this security rule.

The file adheres to the YAML format and follows the expected structure for defining a security rule.

tests/java/use-of-weak-rsa-key-java-test.yml (1)

1-18: Test configuration looks good!

The test configuration covers the necessary scenarios to validate the use-of-weak-rsa-key-java rule:

• Valid RSA key size (2048 bits)
• Invalid RSA key sizes (512 bits, -512 bits, 512.09 bits, 512.0 bits)

No changes needed.

rules/java/security/use-of-weak-rsa-key-java.yml (1)

1-16: Rule configuration looks good!

The rule configuration is well-defined:

• It has a warning severity, which is appropriate for this security issue.
• The message and note provide clear information about the vulnerability and reference relevant CWE and OWASP guidelines.
• The pattern correctly matches RSA key initialization and the constraint ensures that key sizes less than 2048 bits are flagged.

No changes needed.

rules/kotlin/security/use-of-weak-rsa-key-kotlin.yml (1)

1-18: Rule configuration looks good!

The rule configuration for Kotlin is well-defined and consistent with the Java rule:

• It has a warning severity, which is appropriate for this security issue.
• The message and note provide clear information about the vulnerability and reference relevant CWE and OWASP guidelines.
• The pattern correctly matches RSA key initialization and the constraint ensures that key sizes less than 2048 bits are flagged.

No changes needed.

tests/java/unencrypted-socket-java-test.yml (1)

1-23: LGTM!

The test cases for the unencrypted-socket-java rule are well-structured and cover appropriate scenarios. The valid section includes examples of using SSL sockets, while the invalid section includes examples of using unencrypted sockets.

The test cases should effectively validate the correctness of the rule implementation.

Files that changed from the base of the PR and between a85cbfb and b62d49a.

• rules/java/security/des-is-deprecated-java.yml (1 hunks)
• rules/java/security/system-setproperty-hardcoded-secret-java.yml (1 hunks)
• rules/java/security/use-of-md5-digest-utils-java.yml (1 hunks)
• rules/java/security/use-of-rc4-java.yml (1 hunks)
• rules/java/security/weak-ssl-context-java.yml (1 hunks)
• rules/kotlin/security/des-is-deprecated-kotlin.yml (1 hunks)
• rules/kotlin/security/rsa-no-padding-kotlin.yml (1 hunks)
• tests/snapshots/des-is-deprecated-java-snapshot.yml (1 hunks)
• tests/snapshots/des-is-deprecated-kotlin-snapshot.yml (1 hunks)
• tests/snapshots/rsa-no-padding-kotlin-snapshot.yml (1 hunks)
• tests/snapshots/system-setproperty-hardcoded-secret-java-snapshot.yml (1 hunks)
• tests/snapshots/use-of-md5-digest-utils-java-snapshot.yml (1 hunks)
• tests/snapshots/use-of-rc4-java-snapshot.yml (1 hunks)
• tests/snapshots/weak-ssl-context-java-snapshot.yml (1 hunks)
• tests/java/des-is-deprecated-java-test.yml (1 hunks)
• tests/java/system-setproperty-hardcoded-secret-java-test.yml (1 hunks)
• tests/java/use-of-md5-digest-utils-java-test.yml (1 hunks)
• tests/java/use-of-rc4-java-test.yml (1 hunks)
• tests/java/weak-ssl-context-java-test.yml (1 hunks)
• tests/kotlin/des-is-deprecated-kotlin-test.yml (1 hunks)
• tests/kotlin/rsa-no-padding-kotlin.yml (1 hunks)

tests/java/des-is-deprecated-java-test.yml (1)

1-7: LGTM!

The test configuration for the des-is-deprecated-java rule is correctly set up with appropriate valid and invalid code snippets. The valid code snippet uses the secure "AES/GCM/NoPadding" cipher, while the invalid code snippet correctly uses the deprecated and insecure "DES/ECB/PKCS5Padding" cipher to validate the rule implementation.

tests/kotlin/des-is-deprecated-kotlin-test.yml (1)

1-7: LGTM!

The test configuration for the des-is-deprecated-kotlin rule is well-defined:

• The id matches the rule name.
• The valid test case correctly uses the secure "AES/GCM/NoPadding" cipher.
• The invalid test case correctly uses the deprecated and insecure "DES/ECB/PKCS5Padding" cipher.

The test cases align with the intent of the rule to flag the use of the deprecated DES algorithm in Kotlin code.

tests/java/use-of-rc4-java-test.yml (1)

1-9: LGTM!

The test configuration for the use-of-rc4-java rule is well-defined and covers the expected scenarios:

• The valid code snippet correctly uses the secure AES/CBC/PKCS7PADDING cipher.
• The invalid code snippets accurately demonstrate the usage of the insecure RC4 cipher, which the rule aims to flag.

The test cases will effectively validate the rule's behavior in identifying the use of the vulnerable RC4 cipher in Java code.

tests/kotlin/rsa-no-padding-kotlin.yml (3)

1-2: LGTM!

The rule ID rsa-no-padding-kotlin is appropriate and descriptive for a rule that checks for RSA encryption without padding in Kotlin code.

---

3-4: LGTM!

The example correctly demonstrates the usage of RSA encryption with the secure OAEPWithMD5AndMGF1Padding padding scheme in Kotlin.

---

5-8: LGTM!

The examples correctly demonstrate the insecure usage of RSA encryption without padding in Kotlin by specifying NoPadding as the padding scheme. This aligns with the purpose of the rule to flag such instances.

tests/__snapshots__/des-is-deprecated-java-snapshot.yml (1)

1-9: LGTM!

The snapshot test case is correctly configured to match the deprecated DES usage, and the labels section accurately captures the source code range and styling. The test case aligns with the purpose of the des-is-deprecated-java rule.

tests/__snapshots__/des-is-deprecated-kotlin-snapshot.yml (1)

1-9: LGTM!

The snapshot file is well-structured and aligns with the purpose of the des-is-deprecated-kotlin rule. The code snippet correctly demonstrates the usage of the deprecated DES algorithm, and the labels accurately identify the source and positions of the code.

tests/__snapshots__/rsa-no-padding-kotlin-snapshot.yml (1)

1-10: LGTM!

The snapshot test is correctly configured to match the code snippet that the rsa-no-padding-kotlin rule is designed to flag. The labels provide useful metadata for the code snippet, such as the exact source and the start/end positions. This snapshot test will help ensure that the rule is working as expected and will catch any regressions in the future.

tests/__snapshots__/use-of-md5-digest-utils-java-snapshot.yml (1)

1-9: LGTM! The snapshot test case correctly captures the use of MD5 hashing.

The snapshot test case is well-structured and correctly identifies the use of DigestUtils.getMd5Digest().digest() for hashing a password. The metadata provided, such as the source code location and labels, is accurate and follows the expected format for snapshot files.

It's important to note that MD5 is a weak hashing algorithm that is susceptible to collision attacks. It should not be used for password hashing or other security-sensitive operations. Instead, it is recommended to use a secure password hashing algorithm like bcrypt, scrypt, or PBKDF2 with a sufficient number of iterations and a unique salt for each password.

By flagging the use of MD5 hashing from DigestUtils, this rule helps identify instances where insecure hashing practices are being used, allowing developers to replace them with more secure alternatives.

tests/java/use-of-md5-digest-utils-java-test.yml (2)

5-6: LGTM!

The test case correctly uses DigestUtils.getSha512Digest() to hash a password, which aligns with the rule's intent to discourage the use of MD5. The SHA-512 algorithm is a secure choice for hashing sensitive data.

---

8-9: LGTM!

The test case correctly demonstrates an invalid usage of DigestUtils.getMd5Digest() to hash a password. Using the insecure MD5 algorithm from DigestUtils should trigger the rule violation, as intended.

tests/__snapshots__/use-of-rc4-java-snapshot.yml (1)

1-16: LGTM!

The snapshot test configuration for the use-of-rc4-java rule is well-structured and comprehensive. The test cases cover the essential scenarios of using the insecure RC4 cipher directly and passing it to a function. The labels accurately capture the source code range for each test case.

This snapshot test will effectively validate the rule's ability to detect and flag the usage of RC4 cipher in Java code.

tests/__snapshots__/system-setproperty-hardcoded-secret-java-snapshot.yml (1)

1-10: LGTM!

The snapshot test configuration for the system-setproperty-hardcoded-secret-java security rule is well-structured and follows the expected format. The code snippet accurately demonstrates the insecure practice of hardcoding secrets using System.setProperty() for SSL key store and trust store passwords, which the rule aims to detect. The labels correctly mark the positions of the code snippet.

Great job on setting up this snapshot test!

rules/kotlin/security/rsa-no-padding-kotlin.yml (1)

1-14: LGTM!

The rule definition for rsa-no-padding-kotlin is well-structured and targets a specific security vulnerability in Kotlin code. The rule metadata, pattern, and constraints are appropriately defined, and the message and note provide clear guidance for developers.

No issues or improvements are identified in the rule definition.

rules/java/security/use-of-md5-digest-utils-java.yml (1)

1-13: Excellent security rule for detecting insecure MD5 usage!

This rule is well-defined and targets a critical security vulnerability in Java code. The rule correctly identifies the usage of DigestUtils.getMd5Digest and its digest method, which are known to be insecure due to the weaknesses of the MD5 hash algorithm.

The message effectively communicates the security issue and provides clear guidance on using HMAC instead of MD5. The inclusion of relevant references to CWE and OWASP Top 10 enhances the rule's credibility and usefulness.

Additionally, consider the following insights:

• MD5 is vulnerable to collision attacks, where two different inputs can produce the same hash value. This makes it unsuitable for cryptographic purposes, such as password hashing or digital signatures.
• HMAC (Hash-based Message Authentication Code) is a more secure alternative to MD5. It combines a cryptographic hash function with a secret key to provide both integrity and authentication.
• Encourage developers to use modern and secure hashing algorithms like SHA-256 or SHA-3 instead of MD5.

Overall, this rule aligns with industry best practices for secure hashing and will help prevent the use of the weak MD5 algorithm in Java code.

rules/java/security/des-is-deprecated-java.yml (1)

1-16: LGTM!

The des-is-deprecated-java rule is well-defined and provides clear guidance on the security vulnerability. The rule message and note offer sufficient context and references for developers to understand the issue and take appropriate action. The rule pattern correctly identifies the deprecated use of DES, and the warning severity is appropriate given the nature of the security vulnerability.

rules/kotlin/security/des-is-deprecated-kotlin.yml (1)

1-16: LGTM!

The security rule is well-defined and correctly implemented. It addresses an important security concern by warning against the use of the deprecated DES cipher in Kotlin code.

The rule includes:

• Clear id, severity, language, and message fields.
• Actionable message recommending the use of AES instead of DES, along with a reference link.
• Relevant CWE information and additional references in the note section.
• Accurate pattern and constraints to identify the usage of DES with Cipher.getInstance().

The YAML structure follows the expected format for defining security rules. The inclusion of CWE information and references enhances the rule's usefulness and helps developers understand the security implications.

Great job on implementing this important security rule!

tests/java/weak-ssl-context-java-test.yml (1)

1-19: LGTM!

The test cases for the weak-ssl-context-java rule are well-structured and cover a good range of scenarios. The valid test cases correctly use secure SSL/TLS versions or a dynamically obtained SSL context, while the invalid test cases correctly use insecure SSL/TLS versions that should trigger the rule.

Great job on creating comprehensive test coverage for this security rule!

rules/java/security/use-of-rc4-java.yml (1)

1-16: LGTM!

The security rule is well-defined and provides clear guidance on the use of RC4 cipher in Java. The metadata is structured correctly, and the message is informative and actionable. The references add credibility to the rule, and the pattern should accurately detect the security issue.

rules/java/security/weak-ssl-context-java.yml (1)

1-22: LGTM!

The rule definition looks good:

• It correctly identifies the use of weak SSL/TLS versions in SSLContext.
• It provides a clear and informative message about the security issue and how to fix it.
• It uses appropriate severity and categorization.
• It references relevant CWE and RFC documents.
• It uses a regex constraint to match the weak SSL/TLS versions, which is a good approach.

Great job!

tests/__snapshots__/weak-ssl-context-java-snapshot.yml (1)

1-37: LGTM!

The snapshot test correctly identifies the insecure SSL/TLS protocol versions (SSL, SSLv3, TLSv1, TLSv1.1) by highlighting the relevant code segments. The test cases are well-structured and cover a good range of protocol versions.

Files that changed from the base of the PR and between ae12535 and 6ff4438.

• rules/java/security/use-of-aes-ecb-java.yml (1 hunks)
• rules/java/security/use-of-blowfish-java.yml (1 hunks)
• rules/java/security/use-of-md5-java.yml (1 hunks)
• rules/java/security/use-of-sha1-java.yml (1 hunks)
• rules/kotlin/security/system-setproperty-hardcoded-secret-kotlin.yml (1 hunks)
• tests/snapshots/system-setproperty-hardcoded-secret-kotlin-snapshot.yml (1 hunks)
• tests/snapshots/use-of-aes-ecb-java-snapshot.yml (1 hunks)
• tests/snapshots/use-of-blowfish-java-snapshot.yml (1 hunks)
• tests/snapshots/use-of-md5-java-snapshot.yml (1 hunks)
• tests/snapshots/use-of-sha1-java-snapshot.yml (1 hunks)
• tests/java/use-of-aes-ecb-java-test.yml (1 hunks)
• tests/java/use-of-blowfish-java-test.yml (1 hunks)
• tests/java/use-of-md5-java-test.yml (1 hunks)
• tests/java/use-of-sha1-java-test.yml (1 hunks)
• tests/kotlin/system-setproperty-hardcoded-secret-kotlin-test.yml (1 hunks)

tests/java/use-of-md5-java-test.yml (1)

6-7: LGTM!

The code snippet correctly demonstrates the insecure usage of MD5 and is appropriately marked as invalid.

tests/java/use-of-aes-ecb-java-test.yml (3)

3-4: LGTM!

The code snippet correctly uses AES in CBC mode with PKCS7 padding, which is a secure configuration.

---

7-7: LGTM!

The code snippet correctly identifies the use of AES in ECB mode with no padding as an insecure configuration.

---

8-8: LGTM!

The code snippet correctly identifies the use of AES in ECB mode with PKCS5 padding as an insecure configuration.

tests/java/use-of-blowfish-java-test.yml (1)

1-9: LGTM!

The test case configuration is well-structured and the examples are clear and relevant. The valid example demonstrates the use of a secure cipher, while the invalid examples correctly flag the insecure use of the Blowfish cipher.

tests/__snapshots__/use-of-md5-java-snapshot.yml (1)

1-9: LGTM!

The snapshot test is correctly configured to identify the use of the MD5 algorithm in Java code. The test case and labeling are accurate and will help users identify and fix instances where MD5 is used inappropriately.

MD5 is a weak cryptographic hash function that is susceptible to collisions and should not be used for security-sensitive applications. This rule will encourage developers to use stronger alternatives like SHA-256 or SHA-3.

tests/__snapshots__/use-of-sha1-java-snapshot.yml (1)

1-10: Snapshot test configuration looks good!

The snapshot test is correctly set up to validate the use-of-sha1-java rule. It includes a code snippet that demonstrates the usage of the weak SHA1 hash function, and the snapshot labels the specific call to getInstance with SHA1, which is the correct target for the rule.

As additional context, SHA1 is considered a deprecated and weak cryptographic hash function due to its vulnerability to collision attacks. It is recommended to use stronger hash functions like SHA-256 or SHA-3 in new code for improved security.

tests/java/use-of-sha1-java-test.yml (2)

3-6: LGTM!

The valid test case correctly demonstrates code that does not use SHA-1. It is a good example of secure code.

---

8-10: LGTM!

The invalid test case correctly demonstrates insecure usage of SHA-1 in two different ways:

1. Using java.security.MessageDigest.getInstance("SHA1", "SUN") to get a SHA-1 message digest instance.
2. Using DigestUtils.getSha1Digest().digest(password.getBytes()) to generate a SHA-1 hash of a password.

It is a good example of code that should be flagged by the use-of-sha1-java rule.

tests/kotlin/system-setproperty-hardcoded-secret-kotlin-test.yml (1)

1-9: LGTM!

The test configuration for the system-setproperty-hardcoded-secret-kotlin rule is well-defined. It correctly identifies the following:

• Valid code patterns that use a variable to set the javax.net.ssl.trustStorePassword and javax.net.ssl.keyStorePassword system properties.
• Invalid code patterns that use hardcoded string literals to set the same system properties.

This configuration will help detect the use of hardcoded secrets in setting these sensitive system properties, which is a security best practice.

rules/java/security/use-of-md5-java.yml (5)

1-3: LGTM!

The rule metadata is correctly defined with a unique ID, appropriate severity level, and the target language.

---

4-7: LGTM!

The message is clear, informative, and provides a suitable alternative (HMAC) to the insecure MD5 hash algorithm.

---

8-11: LGTM!

The additional notes and references, including the CWE and OWASP Top 10 category, provide valuable context and help users understand the security implications better.

---

12-17: LGTM!

The rule patterns comprehensively cover the common ways of instantiating the MD5 MessageDigest in Java code, ensuring that the insecure use of MD5 is detected effectively.

---

18-20: LGTM!

The constraint correctly matches the MD5 algorithm name using a regular expression, ensuring that the rule is triggered only for the specific insecure hash algorithm.

rules/java/security/use-of-sha1-java.yml (4)

1-12: LGTM!

The metadata for this rule is well-defined:

• The id and language are specified correctly.
• The severity is appropriate for the security issue.
• The message clearly explains the problem with SHA1 and suggests alternatives.
• The note provides useful references to CWE and OWASP.

---

13-17: Great job with the rule patterns!

The 3 patterns effectively cover the different ways SHA1 can be used in Java:

1. $DU.getSha1Digest().digest($$$) for DigestUtils from Apache Commons.
2. MessageDigest.getInstance($ALGO) for the standard MessageDigest API.
3. java.security.MessageDigest.getInstance($ALGO,$$$) for specifying a provider.

Using $$$ ensures any arguments are matched, and $ALGO allows checking the algorithm separately.

---

18-20: The constraint looks good!

The regex constraint on $ALGO will correctly identify usage of SHA1, matching both SHA1 and SHA-1 spellings. This ensures the rule is triggered accurately.

---

1-20: This is an excellent security rule!

The rule is very well-defined to identify usage of the insecure SHA1 hash algorithm in Java code. Key highlights:

• Clear metadata with appropriate severity and useful message and references
• Effective patterns that cover common SHA1 usage scenarios
• Precise constraint to ensure the rule is triggered accurately
• Actionable guidance for developers to use secure alternatives

This rule will significantly help improve the security of Java codebases by catching insecure hashing practices. Great work!

rules/java/security/use-of-blowfish-java.yml (1)

1-17: LGTM!

The security rule for detecting the use of Blowfish cipher in Java code is well-defined and follows the expected format. The rule properties are appropriately set, and the message provides clear guidance and references for remediation. The pattern correctly matches the insecure code.

rules/java/security/use-of-aes-ecb-java.yml (4)

1-10: LGTM!

The metadata section is well-defined and provides clear information about the rule, including:

• A unique identifier for the rule
• The target language (Java)
• The severity categorization (warning)
• A clear and informative message about the security issue and suggested remediation

---

11-17: Excellent references!

The note section provides valuable references to relevant security standards and guidelines, including:

• CWE-327: Use of a Broken or Risky Cryptographic Algorithm
• OWASP Top 10 2017 A3: Sensitive Data Exposure
• OWASP Top 10 2021 A2: Cryptographic Failures
• Additional references to OWASP resources and a blog post about the risks of RC4

These references provide strong support and context for the rule.

---

18-19: Rule pattern looks good!

The rule pattern $CIPHER.getInstance($MATCHES) is correctly defined to detect the use of AES with ECB mode. The pattern uses the variables $CIPHER and $MATCHES to match the specific code pattern.

---

20-22: Constraints are well-defined!

The constraints section correctly defines a regular expression constraint for the $MATCHES variable. The regular expression ".*AES/ECB/.*" matches the specific use of AES with ECB mode, allowing any characters before and after the "AES/ECB/" string.

rules/kotlin/security/system-setproperty-hardcoded-secret-kotlin.yml (1)

1-22: LGTM!

The security rule is well-defined and follows the YAML structure for defining security rules. It provides useful information to help developers understand the security risk and how to mitigate it.

The rule has the following positive aspects:

• The rule identifier is unique and descriptive.
• The language is correctly set to Kotlin.
• The severity is set to warning, which is appropriate for this type of security risk.
• The message provides a clear explanation of the security risk and how to mitigate it.
• The note provides useful references to OWASP and CWE for more information.
• The rule patterns correctly identify the hardcoded secrets using System.setProperty.
• The constraint ensures that the password is a string literal.