SCANOSS is excited to unveil a significant enhancement to our Code Quality intelligence layer in our knowledgebase: the introduction of a new category of intelligence focused on Secure Coding Practices. This is a game-changer for developers and organizations striving to verify that the third-party code they are using is fortified against security threats. This first release applies to Java, with additional languages to follow.
The 126 Rules for Java - A Closer Look
Our Code Quality layer now incorporates Secure Coding Practices, applying 126 Java rules to every Java file in our Knowledge Base. If your Open Source is exposed, we'll tell you about it. This new layer exposes patterns, anomalies, and practices in your third-party code that could lead to vulnerabilities and other risks.
Practical Implications for Code Scanning:
The 126 rules that we've run against our Knowledge Base for Java cover a wide array of security concerns, from common vulnerabilities like cross-site scripting (XSS) and injection flaws to more intricate issues like improper error handling and insecure data storage practices. To get an idea, here's three representative community rules from SEMGREP that SCANOSS has considered during the scan of our Knowledge Base and gotten a vast number of hits on:
unsafe-reflection.java: This rule targets the risky use of the Class.forName function with user input, which could lead to unauthorized class instantiation and unexpected application behaviour, such as security breaches. The rule advises against using non-literal values in Class.forName or employing an allowlist for inputs to mitigate this risk
unrestricted-request-mapping.java: A rule that identifies Java Spring endpoints that do not specify an HTTP method, making them accept all HTTP methods. This can lead to security vulnerabilities, particularly in bypassing CSRF protectio .
Formatted-sql-string-java: This rule detects string-formatted SQL queries in Java, which are vulnerable to SQL injection if they incorporate user-controlled variables. It advises against using methods like String.format for constructing SQL queries to prevent security risks.
Conclusion
The introduction of Secure Coding Practices for Java into our Code Quality intelligence layer represents a pivotal advancement in the Open Source intelligence that SCANOSS offers development organizations. It's a step that goes beyond mere code quality; it's about building a foundation of security and trust in every line of third-party code that developers use.
This enhancement is a testament to our commitment to assisting developers with actionable intelligence early in the development process.
To learn more, head to SCANOSS and get in touch.
Stay tuned for Secure Coding Practices in more languages!
Comments