Meet Sigrid®

Continuous software portfolio governance is the ongoing practice of tracking and steering the quality, risks, and evolution of software across the entire portfolio. It gives leaders a current view of the landscape, not a periodic snapshot.

LLMs, AI coding assistants, and agents can generate and even help review code—but they’re fundamentally limited.

They rely on associative, pattern-based reasoning, which makes them fast but not always accurate. They can miss critical flaws because they don’t have full system context or understanding of your architecture. That’s why you need deterministic analysis tools and expert reviews to properly govern AI-generated code.

AI coding assistants and agentic AI holds great promise for accelerating software development and modernizing legacy systems. However, they also introduce significant challenges related to code quality, security, architecture, and even legal issues.

Enterprises scaling AI need comprehensive solutions to manage these risks effectively.

Sigrid® findings are based on standardized, repeatable measurements of source code, not one-off opinions. Software Improvement Group measures software against globally recognized standards, including ISO/IEC 25010 for software quality, ISO/IEC 5055 for code quality, and ISO/IEC 27001 for information security management.

That approach is backed by independent accreditation. We are the world’s first and only laboratory accredited under ISO/IEC 17025 for software quality analysis, certified by TÜViT. 

For a deeper look at the standards and methodology behind these findings and our models, see our more detailed page on the topic.

Software does not stand still. Systems change, dependencies shift, and risks build up over time. A continuous approach helps organizations spot issues before they become problems and help make better decisions.

Sigrid® is technology-agnostic and currently has supported over 300 different technologies. Naturally, we support popular languages such as Java, C#, and Python. We also support some more specialized but still widely-used technologies like COBOL, PL/SQL, and Docker.

On average, we were adding about 20 new technologies per year. If there's a specific technology you're curious about, we'd be more than happy to check on our current support level. We're always expanding our capabilities, so even if we don't fully support something today, there's a good chance we could add or improve support if needed for your project.

Generally, to assess the quality of something, you need a sense of context. Each piece of software may have a widely different context. To put objective thresholds on code quality, at SIG we use technology-independent code measurements and compare those to a benchmark.

A benchmark on quality is meaningful because it provides an unbiased norm of how well you are doing.

The context for this benchmark is “the current state of the software development market”.

This means that you can compare your source code to the code that others are maintaining.

To compare different programming technologies with each other, the metrics represent a type of abstractions that occur universally, like the volume of pieces of code and the complexity of decision paths within. In this way, system size can be normalized to “person-months” or “person-years”, which indicate of amount of developer work done per time period. Those numbers are again based on benchmarks.

Summarizing, Sigrid compares analysis results for your system against a benchmark of 30,000+ industry systems. This benchmark set is selected and calibrated (rebalanced) yearly to keep up with the current state of software development. “Balanced” here can be understood as a representative spread of the “system population”. This includes anything in between old and new technologies, from anything legacy to modern JavaScript frameworks. In terms of technologies this is skewed towards programming languages that are now most common, because that best represents this current state. The metrics underlying the benchmark approach a normal distribution. This offers a sanity check of being a fair representation and allows statistical inferences on “the population” of software systems.

The code quality score compared to the benchmark is expressed in a star rating on a scale from 1 to 5 stars. It follows a 5%-30%-30%-30%-5% distribution.

Technically, its metrics range from 0.5 to 5.5 stars.

This is a matter of convention, but it also avoids a “0” rating score because 0 is not a meaningful end on a quality scale. The middle 30% exists between 2.5 and 3.5, with all scores within this range rated as 3 stars, representing the market average.

Even though 50% of systems necessarily score below average (3.0), 35% of systems will score below the 3-star threshold (below 2.5), and 35% will score above the 3-star threshold (above 3.5). To avoid a suggestion of extreme precision, it is helpful to think about these stars as ranges, such that 3.4 star would be considered “within the expected range of market average, on the higher end”. Note that calculation rounding tolerances are always downwards, with a maximum of 2 decimals of precision. So, a score of 1.49 stars will be rounded down to 1 star.

Sigrid CI can be used to publish main branch code to Sigrid for baseline analysis, and to get feedback on pull requests. 

Integrating Sigrid into your development environment serves two purposes. First, it will publish your systems to Sigrid after every change, ensuring Sigrid is always-up-to-date and removing the need for manual uploads. Second, it allows you to provide your development teams with direct feedback after each change. Sigrid supports integrations with 10+ different development environments, such as GitHub or BitBucket.

Sigrid uses your anonymized repository history to calculate metrics on which code has been changed, and when those changes were made. These statistics do not contain personal information. In fact, if you use Sigrid CI, the developer names will be anonymized client-side, so before anything is published to Sigrid.
You can find more information on Sigrid data usage in our Privacy Statement.