![[syndicated profile]](https://www.dreamwidth.org/img/silk/identity/feed.png){kind=small}
mamohanraj_feed) wrote2025-07-25 10:02 pm
mamohanraj_feed) wrote2025-07-25 08:06 pmmamohanraj_feed) wrote2025-07-25 07:58 pmmamohanraj_feed) wrote2025-07-25 04:07 pmmamohanraj_feed) wrote2025-07-24 03:01 pmmamohanraj_feed) wrote2025-07-24 01:17 pmkottke_org_feed) wrote2025-07-30 06:16 pmkottke_org_feed) wrote2025-07-30 05:11 pm
From Alan Taylor at The Atlantic, whose curatorial eye I’ve always admired, “a grab bag of curious and interesting historical images from the 20th century”, including photos of the world’s largest banjo, diving archery, death-defying photography, and underwater alligator racing.
Tags: Alan Taylor · photography
kottke_org_feed) wrote2025-07-30 04:07 pmkottke_org_feed) wrote2025-07-30 03:02 pmA perfect game in Tetris is defined as achieving the max score (999,999) in the least amount of time possible, meaning you need to score a bunch of Tetrises in a row (and nothing else) at the highest possible starting speed. A few years ago, a player used a tool to develop a sequence of moves and timing to score a perfect game, proving that it was possible. But could a human do it just by the playing the original game in the way it was intended? Well, you’ve got to watch the video to find out.
I’ve said it before — I love these Tetris analysis videos. Both aGameScout, who did the video above, and Summoning Salt (who made this feature-length video about the history of Tetris world records) are world-class at using video to explain the innovation, competition, and cooperation that allow these players to keep pushing higher and faster, past what anyone thought possible even a few years ago.
Thinking back to the Jackson Goldstone post, what I really want is a aGameScout- or Summoning Salt-caliber video about the differing riding styles of mountain bike riders, how each of them uses their own style to go faster, and where the innovations are happening. I’m sure these videos exist and I just don’t know where to find them, but if they don’t, this would be a hell of an opportunity for someone with ace communication & video editing skills.
Tags: Tetris · video · video games
tidelift_feed) wrote2025-07-30 02:00 pmSonar is excited to announce SonarQube Server 2025.4 release.
Our new 2025.4 release empowers developers with significant advancements to enhance code quality, security, and efficiency across multiple languages. Python developers gain better help for writing more idiomatic and performant code. For Java users, we've introduced code performance rules, full parsing, and complete support for Java 23 and 24 to keep you up-to-date with the latest Java advancements while ensuring your Java code is performant. Additionally we’ve added powerful cross-procedural bug detection for Java which can uncover complex problems often missed by traditional static analysis. C and C++ analysis is significantly faster, drastically reducing analysis times. We’ve added first-class support for Dart 3.8. We’ve continued to expand early access MISRA C++:2023 with new rules, which are now available directly in your IDE to help you achieve compliance earlier in the SDLC as developers code.
Our Static Application Security Testing (SAST) capabilities are extended with full SAST and taint analysis for Go and new taint analysis support for VB.NET, ensuring broader language coverage for security. We’ve added even more secrets detection rules including detecting secrets in YAML, JSON, and Kotlin to deliver best-in-class coverage. The existing JavaScript/TypeScript taint analysis engine has been replaced by a more robust analysis engine for more accurate security findings. We’ve enhanced existing security reports, to simplify compliance documentation and auditing. Lastly, in SonarQube Advanced Security, we now support PHP (Packagist) dependencies, automatically detect new vulnerabilities without requiring reanalysis to keep your projects continually secure, provide customizable risk severity so you can prioritize issues based on your context, offer machine-readable SCA reports for easier integration with security workflows, and dependency risks caught in the IDE.
The 2025.4 What's New page and our SonarQube Server release notes provide more details about the release.
If you’re on a version older than the 2025.1 LTA release, upgrade to the SonarQube Server LTA before upgrading to the latest version. Check out this helpful checklist for a smoother upgrade. Watch the on-demand LTA upgrade webinar, which explains a step-by-step approach and highlights common pitfalls encountered during the upgrade.
tidelift_feed) wrote2025-07-29 02:00 pmModern software development is caught between two powerful forces. On one hand, generative artificial intelligence (AI) coding tools are supercharging development velocity at the expense of rigorous security review. On the other, the European Union's Cyber Resilience Act or CRA (Regulation EU 2024/2847), along with related legislation such as the Product Liability Directive (PLD), is ushering in an era of strict regulatory accountability, placing the liability for preventing cybersecurity failures squarely on manufacturers. This creates a critical paradox: the very tools used to build software faster are introducing security risks at a scale that manual oversight cannot manage, and the CRA makes manufacturers legally responsible for these risks.
For all companies that do business in the EU – notably, not just companies based in the EU – this new reality signals significant new complications for software lifecycle and supply chain management, especially when using AI coding tools. The CRA introduces mandatory cybersecurity requirements that apply throughout a product's entire lifecycle, covering “products with digital elements” (PDEs) from design to end-of-life. With severe penalties for non-compliance—up to €15 million or 2.5% of global turnover—the CRA legally mandates a new model: one that demands organizations move fast, but prove their products are built right from the start.
The CRA's scope is intentionally broad, applying to all PDEs made available on the EU market, regardless of where the manufacturer is located. This includes a wide array of products, such as baby monitors, networked household gadgets, B2B software, connected consumer electronics, and more. Its core technical requirements, detailed in Annex I, are extensive. The cornerstone is the mandate to ship products "without known exploitable vulnerabilities" and to deliver them with a "secure by default configuration." Other essential obligations include protecting against unauthorized access, ensuring the confidentiality and integrity of data, limiting attack surfaces, and minimizing data processing.
The Act also establishes ongoing responsibilities. Manufacturers must implement robust vulnerability handling processes, which includes creating a Software Bill of Materials (SBOM) for their products. They are required to provide security updates for a support period of at least five years. Perhaps the most urgent requirement is the 24-hour deadline to notify the EU's cybersecurity agency, ENISA, of any "actively exploited vulnerability," a rule that demands mature and well-practiced incident response plans. Proving compliance requires meticulous documentation, including a cybersecurity risk assessment.
The only exceptions are for products where sector-specific legislation with equivalent cybersecurity requirements already exists, such as for medical devices, aviation, and cars. Certain open-source software developed or supplied outside the course of a commercial activity is also excluded from the direct obligations placed on manufacturers, though the commercial products that incorporate this software remain fully within scope. This wide-ranging applicability ensures that the CRA establishes a horizontal cybersecurity baseline for the digital economy.
The rapid adoption of AI coding assistants introduces a new variable for developers and manufacturers into the CRA compliance equation. These tools accelerate development, but they also pose significant security risks. Trained on massive public code repositories, AI models learn from and replicate the countless vulnerabilities and insecure coding patterns contained within that data. Studies have shown that a substantial portion—approximately 40% in some cases—of AI-generated code contains security flaws like those on the CWE Top 25 list. Some examples of increased security exposure include:
The CRA provides an unambiguous answer to the question of who is responsible for these AI-induced flaws: the manufacturer of the final product. The regulation makes no distinction between code written by a human and code suggested by AI. To meet the CRA's standard of due diligence, organizations must treat AI-generated code as an untrusted input that requires the same, if not a more stringent, level of automated security analysis as any third-party library.
Addressing the dual challenges of the CRA and AI-generated code requires a framework that embeds automated security verification throughout the software development lifecycle.
The Cyber Resilience Act's deadlines are firm and approaching. The obligation to report actively exploited vulnerabilities applies from September 11, 2026, with the full application of most other provisions following on December 11, 2027.
Organizations should begin preparing immediately by assessing which products fall under the CRA's scope, conducting a gap analysis of their current processes, evaluating their security tooling, and formalizing their incident response plans to meet the tight 24-hour reporting window.
The SonarQube platform integrates all the aforementioned capabilities into a single solution, ensuring a user-friendly and streamlined experience for developers and quality gatekeepers alike. This comprehensive approach allows teams to implement Sonar’s “trust and verify” approach to maintaining high standards of code quality and security, even as they adopt AI coding solutions, ultimately leading to more robust and reliable applications.
Software teams that treat the CRA as a mere compliance checklist to be managed with fragmented tools or manual processes will struggle to keep pace, exposing themselves to significant legal and financial risk. In contrast, organizations that embrace the spirit of the Act—a deep-seated commitment to producing high-quality, secure, and reliable software from the start—can transform this regulatory obligation into a powerful competitive advantage. By implementing an integrated framework to govern the quality and security of all code, regardless of its origin, companies can not only meet their legal duties but also build more robust products, foster greater customer trust, and ultimately innovate faster and more safely.
tidelift_feed) wrote2025-07-29 01:00 pmWelcome back to our blog series on the latest Java features and the new rules in SonarQube designed to check for the proper usage of javadoc and markdown, ensuring your code adheres to best practices and avoids common pitfalls.
We’ve covered Java 22, and are now getting into Java 23, which introduces several new language features. We’ll focus on enhancing documentation, and how to leverage the new features with simple examples.
Java 23 introduces an enhancement to JavaDoc, allowing comments that begin with three slashes `///` to be interpreted as JavaDoc comments using Markdown syntax. This subtle yet significant change aims to simplify the process of writing rich and readable documentation directly within the code. By leveraging Markdown, developers can more easily format their JavaDoc comments with features like bold text, italics, lists, and code blocks, without needing to learn specific JavaDoc HTML tags, officially detailed in JEP 445. This streamlines the documentation process, making it more intuitive and encouraging the creation of better-formatted and more accessible API documentation.
SonarQube has introduced new rules to assist developers in adopting Java 23's Javadoc and Markdown enhancements. These rules — including S7476 and S7474 — ensure that documentation is consistently formatted, easy to read, and free from common migration pitfalls. By leveraging these rules, developers can seamlessly integrate Markdown into their Javadoc comments to improve clarity and maintainability, ensuring that the old code is completely aligned with the new features.
With Java 23, comments starting with /// are now officially interpreted as Javadoc comments that use Markdown syntax. Before, they were simply ignored by the Javadoc tool and treated as regular implementation comments. This change means that existing comments in your codebase could unintentionally become part of your public API documentation after migrating to Java 23. This can lead to confusing or unprofessional-looking documentation and increases the effort required for migration. This new rule helps you find these cases in advance so they can be corrected.
Noncompliant Code Example:
public class Calculator {
/////////////////////////////////////////////
// A section for advanced math operations. //
// These are experimental. //
/////////////////////////////////////////////
public int add(int a, int b) {
/// This is a super important implementation note for the add method.
/// It should not be in the final Javadoc.
return a + b;
}
}In the example above, both the decorative block comment and the /// comment would be incorrectly processed as Javadoc in Java 23.
Compliant Solution:
public class Calculator {
// A section for advanced math operations.
// These are experimental.
public int add(int a, int b) {
// This is a super important implementation note for the add method.
// It should not be in the final Javadoc.
return a + b;
}
}The compliant solution is to ensure regular comments use the standard // syntax.
Java 23's introduction of Markdown in Javadoc comments is a significant step towards cleaner, more readable documentation. To maintain consistency, it's best to fully embrace Markdown syntax and avoid mixing it with legacy HTML tags (like <b>, <code>, <li>) or old Javadoc block tags (like {@code} or {@link}). Mixing these styles can lead to inconsistent rendering across different tools and makes the raw documentation harder to read. This rule encourages developers to use the modern, more concise Markdown syntax wherever possible.
Noncompliant Code Example:
///
/// A utility class for String operations.
///
/// Use this class to perform common manipulations. For more details,
/// see {@link java.lang.String}.
/// You can also use {@code new StringManipulator()}.
///
public class StringManipulator {
// ...
}
This Javadoc mixes bold HTML tags with Javadoc's {@link} and {@code} tags. The clean, modern approach is to use Markdown for all formatting.
Compliant Solution:
///
/// A utility class for **String** operations.
///
/// Use this class to perform common manipulations. For more details,
/// see [String].
/// You can also use `new StringManipulator()`.
///
public class StringManipulator {
// ...
}By adopting a consistent Markdown style, your documentation becomes cleaner, easier to write, and future-proof.
By embracing the new features in Java 23 — such as Markdown in Javadoc — developers can write more efficient, and more maintainable code resulting in a higher-quality code. However, staying abreast of these evolving language enhancements and consistently applying best practices can be challenging.
This is where tools like SonarQube, become invaluable. They provide automated checks that help ensure your code not only leverages these modern features correctly but also adheres to high-quality standards, ultimately improving code clarity and overall project quality.
tidelift_feed) wrote2025-07-28 02:00 pmThis article explores Volume 4 of a four-part report series. Click here to start from the beginning.
Over the last few weeks, Sonar's The State of Code report series has helped development teams explore the real-world state of software development. We’ve uncovered the most common reliability bugs, security vulnerabilities, and maintainability issues found across billions of lines of code. This article covers the fourth and final report in the series, where we shift from universal principles to the specific challenges within the programming languages that development teams use every day.
This analysis is not based on surveys, but on concrete data from the real issues developers are encountering in their work. Our findings are drawn from an analysis of Sonar's massive dataset from the last six months of 2024, which includes:
Here are some of the most prevalent language-specific issues we uncovered, why they create problems for development teams, and how to fix them before they ever reach production.
One of the most common security issues in Java code is leaving debug features enabled in production. This often happens when a developer uses a feature like a stack trace printout for troubleshooting and forgets to remove it before deployment—an easy mistake to make, but one with severe consequences.
The most frequent bug in JavaScript is the presence of statements that have no side effects and don’t change the program’s control flow. Often a sign of incomplete refactoring or a simple typo, this dead code can completely alter an application's logic. A classic case is an “if” statement followed by a lone semicolon, which silently causes the condition to be ignored and the next block of code to run unconditionally.
A critical security risk frequently observed in Python applications is the use of unencrypted, clear-text protocols like FTP and HTTP. Using unencrypted channels is the digital equivalent of sending login credentials on a postcard, exposing applications to data theft, malware, and malicious redirects.
Understanding and addressing these common pitfalls is about more than just avoiding errors; it’s about mastering the tools of the trade. This has never been more critical, especially as AI coding assistants generate more code than ever before. The quality of the human-written code these tools learn from is paramount to ensuring a secure and reliable software future.
These findings are just the beginning. Our new report provides a much deeper analysis of the top issues across these three major languages, as well as TypeScript, C#, C++, and PHP.
Download The State of Code: Languages report today to see:
tidelift_feed) wrote2025-07-25 01:00 pmAn SOC 2 Type II report is a critical attestation for service organizations, demonstrating their commitment to securely managing customer data over time. It's an in-depth evaluation of the design and operational effectiveness of controls across five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
The report, issued by an independent, licensed CPA firm, instills confidence in customers and stakeholders regarding your company's ability to safeguard their data effectively. It provides crucial assurance that sensitive information is consistently protected by robust internal controls. Achieving SOC 2 Type II builds trust, offers a significant competitive edge, and proactively mitigates data-related risks.
While SOC 2 is less prescriptive than a standard like ISO 27001, its fundamental requirement for well-designed and effectively operating controls is paramount. This can be a significant hurdle for companies, particularly those in rapid software development, often leading to friction between product, engineering, and security/compliance teams.
Key to SOC 2 compliance are controls like CC2.1 (Quality information for internal control), ensuring relevant and high-quality data for decision-making, and CC3.4 (Assessment of impactful changes), for evaluating risks associated with software modifications. More specifically, within the Software Development Life Cycle (SDLC), comprehensive controls are essential to satisfy CC5.2 (Technology Control Activities) and CC5.3 (Deployment of Control Activities). These encompass both technical and administrative controls for technology build and deployment. Additionally, strong change management, as defined by CC8.1 (Change Management Process), with its emphasis on testing, is a universal requirement across all control frameworks.
For development teams striving to meet aggressive deadlines and packed sprints, these crucial controls can become deprioritized. This often results in the deployment of code that, while functional at the moment, becomes difficult to maintain and may contain exploitable vulnerabilities. When auditors request evidence of consistent operation of security controls within the development process, the absence of such evidence can jeopardize a successful SOC 2 Type II recertification.
Sonar's integrated code quality and code security solutions provide a powerful answer to these challenges. By analyzing all code – whether human-written, AI-generated, or third-party open source – Sonar ensures the development of more secure, reliable, and maintainable software, directly contributing to your SOC 2 compliance efforts.
The SonarQube offering, available as self-managed (SonarQube Server) and cloud-based (SonarQube Cloud), along with the free IDE extension (SonarQube for IDE), seamlessly integrates into your development and build processes. This integration automatically enforces CC7.1 (Vulnerability Detection and Monitoring) by providing continuous analysis for all code branches and pull requests.
Sonar enforces code security with SonarQube Advanced Security, an add-on for SonarQube Enterprise that extends SonarQube's powerful analysis to protect your entire software supply chain, with a particular focus on open source dependencies. It achieves this through two major capabilities: Software Composition Analysis (SCA) and advanced Static Application Security Testing (SAST). This comprehensive approach directly supports your efforts in meeting CC7.1 and demonstrating a proactive stance on vulnerability management.
Development teams can also benefit from Sonar's broad coverage of other critical SOC 2 control requirements:
The impact on developers is minimal and predictable, as their primary task becomes correcting identified findings. With the SonarQube for IDE plugin, this process shifts even further left to catch issues in real-time as developers are coding — what we like to call “start left”. It’s also easy to ensure comprehensive coverage across the entire development stack with static analysis rules for 30+ programming languages.
Project managers gain access to consolidated statistics through rich reports and dashboards, providing insights into findings and outstanding issues. This ensures consistent measurement of quality and security across all products, departments, and teams. Furthermore, Quality and Security Gates can be fine-tuned to promote continuous improvement, aligning with SOC 2's emphasis on ongoing control effectiveness.
Having all changes meticulously tracked and reported through enterprise reports also significantly simplifies the process of providing auditors with evidence of secure and high-quality code. You can also clearly demonstrate continuous improvement to the auditor, by showcasing the raising of quality gates and a reduction in the number of findings over time, directly supporting the operational effectiveness aspect of your SOC 2 audit.
Beyond technical controls, Sonar continuously educates developers through its 6,000+ static analysis rules, effectively demonstrating compliance with CC1.4 (Competence of Personnel). This highlights your organization's commitment to developing and retaining competent individuals, a crucial element of a strong control environment.
Ready to enhance your code security and streamline your SOC 2 compliance journey? Integrate SonarQube Server, SonarQube Cloud, or SonarQube for IDE into your development workflow to automatically enforce well-designed and operative SOC 2 controls within your SDLC.
Start your journey towards robust, secure code and efficient SOC 2 compliance by requesting a demo or evaluating SonarQube Server or SonarQube Cloud today!
tidelift_feed) wrote2025-07-23 05:00 amThe rapid adoption of AI-powered code assistants like GitHub Copilot, Windsurf, and Cursor has transformed software development, but it has also introduced new code quality and code security challenges. A recent blog from Pillar Security, "New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents" highlights a critical supply chain attack vector. This case highlights an issue where configuration files were manipulated through hidden Unicode characters, which is a vector now commonly referred to as the "Rules File Backdoor".
To direct code assistant output, developers often embed instructions in READMEs or specialized files (e.g., Cursor's .mdc). While these files are widely adopted across teams and open-source communities, they're frequently shared and integrated into projects with little to no security validation, posing a potential risk. These files, typically perceived as safe because they are non-executable, can be used to manipulate code generation.
This “Rules File Backdoor” vulnerability leverages hidden malicious instructions, often embedded using invisible Unicode characters, within configuration files that guide AI code agents. These concealed prompts can instruct the AI to generate insecure or even backdoored code, all while remaining undetected during traditional code reviews. Because configuration files are often trusted implicitly, they present an attractive target for attackers.
The mechanisms exploited in the "Rules File Backdoor" serve as reminders of several well-known challenges in the software development process:
At Sonar, we recognize the importance of securing every stage of the development pipeline, especially as AI tools become more deeply integrated into coding workflows. SonarQube is designed to address a broad range of vulnerabilities through its extensive set of static code analysis rules and integrated code quality and security features. Its capabilities can be directly mapped against the risks demonstrated by the "Rules File Backdoor" case. SonarQube (Server and Cloud) can detect hidden characters and suspicious patterns within configuration files used by tools like Copilot and Cursor. By surfacing these invisible threats, SonarQube empowers development teams to identify and remove malicious instructions before they can influence code generation.
This proactive approach is essential for preventing the weaponization of large language models (LLMs) and ensuring that generated code remains secure and free from hidden vulnerabilities. By integrating SonarQube into your development process, you can safeguard your software supply chain against sophisticated and stealthy attacks that exploit AI-powered tools.
SonarQube has measures to detect suspicious Unicode sequences through rules. These rules target control characters that are commonly used to obfuscate malicious code. By alerting developers to these unexpected characters, SonarQube helps prevent hidden injections from influencing code behavior.
This is an example of a rules configuration file for Cursor:
When a developer asks to create a new endpoint, the requested protection is added (ie: the ADMIN role)
This is an example of a another rules configuration file for Cursor containing hidden instructions:
It is similar for a human to the previous one without hidden instructions.
When a developer asks for a new endpoint to be created, this time, there is no longer any of the protection requested:
SonarQube can detect these hidden unicode characters in all files so developers understand the security risks and fix the configuration files.
With SonarQube, configuration files are now subject to the same level of scrutiny as source code.
As the landscape of software development evolves, so do the tactics of malicious actors. Robust code quality and code security measures, like those provided by Sonar, are vital to protect your codebase from emerging threats. Employing SonarQube not only helps in catching potential issues before they escalate but also fosters a proactive culture of security and quality: it is an indispensable tool in modern software development.
tidelift_feed) wrote2025-07-21 10:00 pmUnderstanding the new features in Java is crucial for writing updated, efficient, and high quality code. To assist developers in adopting these changes correctly, SonarQube has introduced several new rules designed to check for the proper usage of unnamed variables and patterns, ensuring your code adheres to best practices and avoids common pitfalls.
In this three-part blog series, we’ll be covering the latest features in Java 22, 23, and 24, and the new SonarQube rules to help you effectively take advantage.
In this first blog, we’re digging into Java 22, which introduces several new language features. But there’s one particularly important — the Unnamed variables and patterns with simple examples.
A significant and welcome addition in Java 22 is the finalization of Unnamed variables and patterns, officially detailed in JEP 456. This feature enhances code clarity by allowing developers to use an underscore (_) for variables and patterns that are intentionally left unused.
This elegantly addresses common scenarios where a variable is required by syntax but has no relevance to the business logic, such as a caught exception object that is never inspected or a loop variable in an enhanced for-loop where only the iteration count matters.
By replacing these placeholder names with a simple underscore, developers can reduce code clutter, eliminate "unused variable" warnings, and more clearly express their intent. This ultimately leads to higher-quality, more maintainable Java code.
SonarQube introduces a suite of new rules to ensure proper adoption of Java 22's unnamed variables and patterns. These rules — including S7466, S7467, and S7475 — guide developers in leveraging this feature for more maintainable code. Adhering to these guidelines enables teams to significantly improve code clarity and address redundant warnings.
When declaring an Unnamed variable, the type declaration often becomes redundant. The primary purpose of an Unnamed variable is to signal that it won't be used, making its specific type less critical. Using var in this context enhances conciseness and maintains focus on the intent: to intentionally ignore the variable.
Let's look at an example. When iterating over a collection where only the number of iterations matters, the element itself is not used.
Noncompliant code example:
int count = 0;
for (String element : myList) { // "element" is unused
count++;
}In Java 22, you can use an Unnamed variable. However, explicitly declaring the type is unnecessary.
Noncompliant code example:
int count = 0;
for (String _ : myList) { // The type "String" is redundant
count++;
}This is where rule S7466 comes in, suggesting a cleaner, more concise approach.
Compliant solution:
int count = 0;
for (var _ : myList) {
count++;
}By using var, the code becomes less verbose and the intent remains clear.
A common scenario in Java is catching an exception where the exception object itself is not needed. Previously, developers would have to declare the exception variable, even if it was never referenced, leading to "unused variable" warnings from static analysis tools. Java 22's Unnamed variables provide a perfect solution for this.
Consider a try-catch block where the simple fact that an exception was caught is enough, and its details are irrelevant.
Noncompliant code example:
try {
// some operation that might throw an exception
} catch (NumberFormatException e) { // "e" is unused
// log that the format was invalid
}While functional, the declaration of e is noise. Using an unnamed variable is a better approach, and this is what SonarQube now recommends.
Compliant solution:
try {
// some operation that might throw an exception
} catch (NumberFormatException _) {
// log that the format was invalid
}This compliant solution is cleaner and explicitly communicates that the exception object itself is not important for the handling logic.
Record patterns, a powerful feature for deconstructing record instances, are also enhanced by unnamed patterns. When pattern matching against a record, you might only be interested in a subset of its components. With Unnamed patterns, you can ignore the components you don't need.
When an entire record component is unused in a pattern match, specifying its type is superfluous. Rule S7475 encourages the removal of these unnecessary type declarations, leading to more readable and less cluttered code.
Imagine you have a ColoredPoint record and you only need the Point component in your logic.
Noncompliant code example:
if (obj instanceof ColoredPoint(Point p, Color c)) { // "c" is unused
// logic that only uses p
}In Java 22, you can use an unnamed pattern for the Color component. However, including the type is not necessary if the component is completely ignored.
Noncompliant code example:
if (obj instanceof ColoredPoint(Point p, Color _)) { // The type "Color" is redundant
// logic that only uses p
}The most concise and readable version, as enforced by SonarQube, omits the type for the unused component entirely.
Compliant solution:
if (obj instanceof ColoredPoint(Point p, _)) {
// logic that only uses p
}This approach makes the code more focused on the relevant data, improving maintainability.
By embracing the new features in Java 22 —such as Unnamed variables and patterns—developers can write more efficient, and more maintainable code resulting in a higher-quality code. However, staying abreast of these evolving language enhancements and consistently applying best practices can be challenging.
This is where tools like SonarQube, become invaluable. They provide automated checks that help ensure your code not only leverages these modern features correctly, but also adheres to high quality standards, ultimately improving code clarity and overall project quality.
tidelift_feed) wrote2025-07-21 05:00 amThe financial services industry stands at a critical juncture. With the Digital Operational Resilience Act (DORA) now fully in effect across the European Union, financial institutions must demonstrate robust cybersecurity and operational resilience capabilities. At the same time, the pace of digital transformation continues to accelerate, with organizations increasingly dependent on complex software systems and third-party providers.
For compliance professionals and development teams alike, this creates a challenging landscape: how do you maintain regulatory compliance while continuing to innovate and deliver software at speed? The answer lies in embedding security and resilience directly into the software development process, and this is where SonarQube becomes an invaluable ally.
The Digital Operational Resilience Act represents the most comprehensive regulatory framework for managing technology risks in the financial sector. Unlike previous regulations that focused primarily on capital requirements, DORA takes a holistic approach to digital operational resilience, establishing binding requirements that apply uniformly across all EU member states.
DORA's scope is intentionally broad, covering approximately 20 different types of financial entities, such as traditional banks and insurance companies to emerging crypto-asset service providers and crowdfunding platforms. Perhaps most significantly, the regulation extends its reach to critical Information and Communication Technology (ICT) third-party service providers, including cloud platforms, software vendors, and data centers that support financial institutions.
The regulation is built around six interconnected pillars that form a comprehensive framework for digital resilience:
ICT risk management and governance requires financial entities to establish robust frameworks for identifying, protecting against, detecting, responding to, and recovering from ICT risks. This includes implementing comprehensive security policies, conducting regular risk assessments, and ensuring business continuity planning.
ICT-related incident management and reporting harmonizes incident response across the EU, requiring standardized reporting of major incidents within strict timelines—initial notification within 24 hours, intermediate reports within 72 hours, and final reports within one month.
Digital operational resilience testing mandates comprehensive testing programs, including annual vulnerability assessments and, for critical institutions, advanced threat-led penetration testing every three years.
ICT third-party risk management addresses the growing dependence on external technology providers, requiring thorough due diligence, ongoing monitoring, and specific contractual provisions to manage concentration risk.
Information sharing arrangements encourage voluntary participation in threat intelligence sharing to strengthen collective defense across the financial sector.
Oversight of critical third-party providers allows for a continuous monitoring of the activities of ICT third-party service providers for financial entities, while protecting the security and confidentiality of customers.
For development teams, DORA compliance presents both challenges and opportunities. The traditional approach of addressing security and compliance as an afterthought, often called "security theater”, is no longer sufficient. Instead, organizations must adopt a "secure by design" philosophy that embeds resilience into every stage of the software development lifecycle.
This shift requires more than just good intentions. It demands tools and processes that can identify vulnerabilities early, manage the risks associated with third-party dependencies, and provide the visibility and documentation needed to demonstrate compliance to regulators.
Consider the complexity of modern software development: applications today typically consist of 70-90% open-source components, rely on numerous third-party services, and are deployed across complex cloud infrastructures. Each of these elements introduces potential risks that must be identified, assessed, and managed throughout the application's lifecycle.
SonarQube, developed by Sonar, offers a comprehensive platform for continuous code inspection that directly addresses many of DORA's requirements. By integrating code quality and security analysis seamlessly into the development workflow, SonarQube enables organizations to build compliance into their software from the ground up.
At its foundation, SonarQube provides powerful Static Application Security Testing (SAST) capabilities that analyze source code to identify vulnerabilities before applications are deployed. This proactive approach is fundamental to meeting DORA's ICT risk management requirements.
SonarQube's SAST engine uses sophisticated taint analysis to track untrusted user input as it flows through an application, effectively detecting complex injection vulnerabilities like SQL injection and Cross-Site Scripting (XSS) with high accuracy and minimal false positives. This framework-aware analysis understands the security controls of popular development frameworks, improving precision and reducing the burden on development teams.
SonarQube also includes comprehensive secrets detection capabilities, scanning for hundreds of patterns covering popular technologies and providers. By integrating with developer IDEs, it can prevent credentials, API keys, and tokens from ever being committed to repositories, a critical capability for maintaining the confidentiality requirements outlined in DORA.
For organizations embracing Infrastructure as Code (IaC), SonarQube provides scanning capabilities for platforms like Terraform, CloudFormation, Azure Resource Manager, Kubernetes, and Ansible. This ensures that the underlying cloud environments are secure from the ground up, supporting DORA's emphasis on comprehensive risk management.
DORA places particular emphasis on managing risks associated with third-party providers and dependencies. This is where SonarQube Advanced Security becomes invaluable, offering Software Composition Analysis (SCA) capabilities that provide comprehensive visibility into the software supply chain.
The SCA capabilities automatically identify known vulnerabilities (CVEs) in both direct and transitive dependencies by cross-referencing against authoritative databases including the National Vulnerability Database (NVD), Open Source Vulnerabilities (OSV), and the CISA Known Exploited Vulnerabilities catalog. It provides crucial context including severity scores, exploitability predictions, and detailed remediation guidance.
Perhaps most importantly for DORA compliance, SonarQube can generate detailed Software Bills of Materials (SBOMs) in standard formats like CycloneDX and SPDX. These inventories are essential for security audits, regulatory compliance, and rapid response to newly discovered vulnerabilities, directly supporting DORA's requirements for maintaining registers of ICT services and managing third-party risks.
The platform's advanced SAST capabilities extend traditional static analysis to include dependency-aware taint analysis. This sophisticated feature traces data flows into and out of third-party libraries, uncovering complex vulnerabilities that arise from the interactions between an application's code and its dependencies, vulnerabilities that other tools often miss entirely.
DORA's testing requirements are comprehensive, mandating annual vulnerability assessments and advanced penetration testing for critical institutions. SonarQube supports these requirements by providing continuous security analysis that serves as a foundation for more advanced testing activities.
The platform's Quality Gates feature is particularly valuable for enforcing organizational security standards. These gates can be configured to fail builds if code doesn't meet predefined thresholds for security, reliability, and maintainability, ensuring that only high-quality, secure code progresses to production environments.
For organizations subject to DORA's advanced testing requirements, SonarQube's detailed vulnerability reports and remediation guidance provide essential input for penetration testing activities. By identifying and addressing basic vulnerabilities through automated analysis, security teams can focus their manual testing efforts on more sophisticated attack scenarios.
One of the most challenging aspects of regulatory compliance is demonstrating adherence to requirements through comprehensive documentation. SonarQube addresses this challenge by automatically generating detailed reports that map to major industry security standards, including OWASP Top 10, CWE Top 25, PCI DSS, STIG, and CASA. Sonar addresses critical NIST Secure Software Development Framework (SSDF) practices for protecting and securing software and responding to vulnerabilities, making it essential for a comprehensive, secure development lifecycle.
These reports provide the evidence base needed for regulatory audits and compliance verification, showing not just what vulnerabilities were found, but how they were addressed and what controls are in place to prevent similar issues in the future. For compliance professionals, this automated documentation significantly reduces the burden of preparing for regulatory examinations.
While meeting DORA's requirements is essential, the ultimate goal is building truly resilient systems that can withstand and recover from operational disruptions. SonarQube contributes to this resilience in multiple ways.
By enforcing code quality standards alongside security requirements, SonarQube helps organizations build more reliable and maintainable software. Clean, well-structured code is easier to debug, modify, and enhance, making applications more resilient to change and less prone to unexpected failures.
The platform's AI Code Assurance capabilities are particularly relevant as organizations increasingly adopt AI-assisted development tools. By applying rigorous quality and security checks to AI-generated code, SonarQube ensures that code from any source (human or AI) meets organizational standards before deployment.
SonarQube itself is designed for operational resilience. The platform offers robust deployment options, including a Data Center Edition designed for mission-critical availability and scalability, and a cloud service hosted in geographically redundant AWS data centers with ISO 27001 and SOC 2 Type II certifications.
For organizations beginning their DORA compliance journey, implementing SonarQube should be approached strategically. Start by integrating the platform into existing CI/CD pipelines to establish baseline security analysis capabilities. This provides immediate value by identifying and addressing obvious vulnerabilities while building familiarity with the platform.
Next, configure Quality Gates to enforce organizational security standards, ensuring that new code meets DORA's requirements for secure development practices. This creates a foundation for ongoing compliance while preventing the accumulation of technical debt.
For organizations with significant third-party dependencies, implementing SonarQube Advanced Security should be a priority. The SCA capabilities provide the visibility needed to manage supply chain risks effectively, while the SBOM generation supports DORA's requirements for maintaining detailed registers of ICT services.
Finally, integrate SonarQube's reporting capabilities into existing compliance workflows. The platform's detailed security reports can serve as evidence for regulatory audits while providing ongoing visibility into the organization's security posture.
While DORA compliance is mandatory for EU financial institutions, organizations that embrace its principles proactively gain significant strategic advantages. By embedding security and resilience into the software development lifecycle, they build more robust systems, reduce operational risks, and create a foundation for continued innovation.
SonarQube enables this transformation by making security analysis accessible to development teams while providing the visibility and documentation needed by compliance professionals. Rather than creating friction between development velocity and regulatory requirements, it aligns these objectives by making secure development practices efficient and sustainable.
The financial services industry is entering a new era where digital operational resilience is not just a regulatory requirement but a competitive differentiator. Organizations that can demonstrate robust cybersecurity capabilities while continuing to innovate will be best positioned to thrive in this environment.
As DORA implementation continues to evolve, financial institutions must remain vigilant about emerging threats and changing regulatory expectations. The regulation's emphasis on continuous improvement means that compliance is not a one-time achievement but an ongoing commitment to operational excellence.
SonarQube's continuous analysis approach aligns perfectly with this philosophy. By providing real-time visibility into code security and quality, it enables organizations to adapt quickly to new threats and requirements while maintaining the high standards demanded by DORA.
The integration of AI and machine learning into software development will continue to accelerate, bringing both opportunities and risks. SonarQube's AI Code Assurance capabilities position organizations to harness these technologies safely while maintaining compliance with regulatory requirements.
The Digital Operational Resilience Act represents a fundamental shift in how the financial services industry approaches technology risk. For organizations subject to its requirements, the choice is clear: embrace a proactive approach to digital resilience or face significant regulatory and operational consequences.
SonarQube provides the tools and capabilities needed to make this transition successfully. By embedding security analysis into the software development lifecycle, managing third-party risks effectively, and providing comprehensive compliance documentation, it transforms DORA compliance from a burden into a strategic advantage.
The path to digital operational resilience begins with secure, high-quality code. With SonarQube as a partner, financial institutions can build the robust, compliant systems that DORA demands while maintaining the agility and innovation needed to compete in an increasingly digital world.
For compliance professionals and development teams working together to meet DORA's requirements, SonarQube offers a common platform that speaks both languages—providing the technical capabilities developers need and the compliance evidence that regulators demand. In an era where security and compliance can no longer be afterthoughts, this integration is not just valuable. It's essential.
tidelift_feed) wrote2025-07-20 10:00 pmThis article explores Volume 3 of a four-part report series. Read the first and second articles.
Forty seconds after its maiden launch, the Ariane 5 rocket, a major European launch rocket, catastrophically failed and exploded in the sky. The cause wasn't an engine malfunction or a structural failure; it was a software bug. A data overflow error, inherited from a reused piece of code, went undetected during testing and caused the rocket’s guidance system to fail. The bug that caused the crash would have been caught before launch if the testing process had included simulations for the new flight parameters; a test with a proper assertion could have flagged the error on the ground.
While few software failures are as spectacular as a rocket explosion, this infamous example highlights a crucial truth: small weaknesses in code and process can lead to devastating consequences. These issues contribute to the staggering annual cost of poor software quality in the U.S., which has climbed to over $2.41 trillion. Much of this cost stems from the daily friction and hidden risks within code that is difficult to understand, modify, and maintain.
But what do these issues look like in the code being written today?
Find out in the third installment of The State of Code report series, focusing on highlighting the common maintainability challenges we found across global codebases. Following our deep dives on reliability and security, this report unpacks the most common "code smells"—weaknesses in design that slow down development, increase technical debt, and elevate the risk of future bugs and failures.
Our findings are drawn from an analysis of Sonar's massive dataset from the last six months of 2024, which includes:
The analysis was revealing. On average, for every million lines of code, Sonar found approximately 53,000 maintainability issues. That translates to about 72 code smells caught per developer per month, representing a silent but significant drain on team efficiency. Below we highlight some of the most frequent problems we uncovered.
The most frequently found code smell relates to how variables are declared in JavaScript. Specifically, it’s the use of the legacy keyword var instead of the modern, more precise let or const.
The most common "blocker" maintainability issue found by our analysis involves unit tests that lack assertions. An assertion is the part of a test that actually verifies if the code produced the correct outcome. Without it, a test only confirms that the code ran without crashing.
Addressing maintainability is crucial for the long-term health of any software project. It directly impacts developer productivity, reduces the risk of future bugs, and lowers the total cost of ownership. As AI coding assistants generate more code than ever, ensuring the quality of the human-written code they learn from is paramount.
This report offers a first step toward understanding the most common maintainability issues affecting development teams today. By catching these problems early, teams can build a more stable, resilient, and secure foundation for the future.
These findings are just the beginning. Download The State of Code: Maintainability report to see:
Stay tuned for the next report in our series, where we’ll explore language-specific challenges impacting codebases globally.
thecityny_feed) wrote2025-07-30 06:15 pm
The cost of a subway, bus or paratransit trip could hit $3 next year under proposed fare and toll increases unveiled Wednesday by the MTA.
The proposed 10-cent bump on single-ride New York City Transit trips would be the first since the price of a single ride went up to $2.90 in August 2023. It would also be the latest in a pattern established more than a decade ago, when the MTA opted for every-other-year increases as the transit agency emerged from the 2008 financial crisis.
“This has been good for customers’ wallets compared to what happened in the 1980s where you saw double digit increases happening,” Jessie Lazarus, the agency’s deputy chief for commercial ventures, said at an MTA board meeting Wednesday. “It’s also helped keep service levels steady, which is also good for customers.”
The proposed hikes would also affect the MTA’s two commuter railroads along with its bridges and tunnels, where motorists could have to pay an additional 7.5% in tolls. Officials described the increases as “small, stable and predictable” during a period of high inflation.
“Transit is one of the few things that makes New York affordable and we’re keeping it that way,” Janno Lieber, MTA chairperson and CEO, told reporters after the board meeting. “In fact, since 2018, according to the comptroller, the price of transit has gone up just 16%, while the price of housing — which is the central issue in our affordability crisis — has gone up 68%.”
But the jump to $3 could be especially striking for straphangers, given that the MTA has previously floated proposals to hit the milestone, but has so far avoided it.
“If the MTA base fare had kept up with inflation … we’d already be at $3.50 per trip,” Lazarus said. “As you may know, that ‘pizza principle’ — this homegrown economic theory that the cost of a subway [ride] and the cost of a slice should always be the same — really collapsed in the last few years in this period for the first time since the 1960s.”
Danny Pearlstein, policy analyst for the advocacy organization Riders Alliance, conceded that the thinking about fares as tied to the price of a slice no longer applies, while adding that the proposed $3 subway or bus fare would be an undeniable milestone for riders.
“The pizza-slice principle is, unfortunately, outmoded now that we have $1.50 slices and luxury slices,” he said. “With the stratification of pizza also comes the stratification of fares.”
Starting next month, commuters will have a chance to air their thoughts on the planned changes to the MTA’s fare and toll structures at public hearings throughout the city and region. The agency’s board must also vote on the plan.
Mayor Eric Adams, who recommends four picks to the 23-member MTA board, said he would push for all board members to reject the fare proposal.
“We strongly oppose this fare increase and remain committed to fighting for a more affordable and equitable city,” Adams said in a statement Wednesday evening.
MTA officials said the agency has gotten a boost from revenues that are better than projected, a drop in fare evasion and finding cost savings that came in at close to half a billion dollars.
Once approved by the MTA board in the fall, the new subway and bus fares would kick in on Jan. 4. Those include discounted fares potentially going up from $1.45 to $1.50. The increase was initially set to kick in next month, but the MTA adjusted the timetable because it would be unable to complete the public hearing process in time.
With the MTA transitioning fully into the OMNY tap-and-go fare-payment system by the start of 2026, the 7-day and 30-day unlimited-ride options familiar to MetroCard users will be retired.
Bus and subway riders who can now ride for free after spending $34 on 12 trips would have to take $36 on trips before the free rides take effect.
On express buses that connect commuters from the boroughs with Manhattan, the $7 base fare would climb to $7.25, with reduced-fare commuters riding for half price during off-peak hours.
Fare-capping would also be expanded to express buses, with seven-day fares capped at $67, instead of the current rate of $64.
“Express bus riders would never pay more than $67 in any seven-day period and they’d receive unlimited express bus, local bus and subway rides,” Lazarus said.
Sales of the MetroCard, the fare-payment system that has had riders swiping and dipping plastic cards for three decades, will end at the end of the year.
On the Long Island Rail Road and Metro-North, one-way peak-period fares would go up an average of 4.4%, MTA officials said, along with weekly and monthly and weekly tickets.
“All monthly tickets are still priced below pre-pandemic levels and no monthly ticket is more than $500 even in the farthest zones,” Lazarus said.
Our nonprofit newsroom relies on donations from readers to sustain our local reporting and keep it free for all New Yorkers. Donate to THE CITY today.
The post MTA Wants New Year to Start With Fare Hike to $3 appeared first on THE CITY - NYC News.