ISO/IEC 5055: ISO/IEC 5055 – Tutorial (about 60 minutes)

ISO/IEC 5055 is an international standard that defines how to measure the internal, structural quality of software automatically, by analysing its source code. It counts severe coding and architecture weaknesses that threaten four quality characteristics: security, reliability, performance efficiency and maintainability. Developers, architects, quality and security engineers, IT managers and buyers of outsourced software use it to set objective quality targets, compare releases and write measurable acceptance criteria. After this tutorial you will be able to explain what the standard measures and why, read an ISO/IEC 5055 report critically, plan a measurement programme around it and connect it to the other quality standards you already use.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO/IEC 5055:2021, Information technology – Software measurement – Software quality measurement – Automated source code quality measures, first edition, published in 2021 by ISO and IEC through their joint technical committee JTC 1. Its content is the Automated Source Code Quality Measures (ASCQM) specification developed by the Consortium for Information & Software Quality (CISQ) and adopted by the Object Management Group (OMG) as version 1.0 in January 2020; OMG later published ASCQM 1.1 (July 2022) with corrections. The 2021 edition (published 30 March 2021) is still the current published ISO/IEC edition. Its first five-yearly systematic review took place in 2026: national catalogues mirroring ISO data show the review closed in June 2026 (stage 90.60), and no decision to confirm, revise or withdraw had been published when this course was checked. CISQ has also developed related measures, such as a data protection measure (published by OMG in 2022) and a resource sustainability measure that is still in development; these are separate from the 2021 edition, so this course teaches ISO/IEC 5055:2021. Verified 2026-10-29 against the CISQ standards pages, the OMG specification catalogue, the IEC webstore, a national standards body's catalogue entry and the MITRE CWE view for the CISQ quality measures. The ISO catalogue page blocks automated access, so check its life-cycle box yourself before quoting the status in a contract.

A note on copyright: this tutorial explains the standard in its own words. It does not reproduce the standard's weakness lists, detection patterns or definitions. For contractual or audit use, buy the official text from ISO, IEC or your national standards body, or obtain the equivalent OMG specification.

Who it is for: software engineers and team leads, software architects, test and quality managers, application security engineers, IT portfolio and vendor managers, and auditors who need an objective view of the code they build, buy or maintain. No earlier knowledge of ISO standards or of CISQ is assumed.

Prerequisites: none. A general idea of how software is written, built and released, and what a static analysis tool does, will make the examples easier to follow.

Learning objectives. After this course you will be able to:

Explain the problem ISO/IEC 5055 solves and how it differs from functional testing and from process standards.
Define the key terms: structural quality, weakness, CWE, detection pattern, occurrence, base measure and derived measure.
Describe how the standard is organised, from the four quality characteristics down to counted weakness occurrences.
Plan and run an ISO/IEC 5055 measurement programme with sensible scope, tooling, baselines, thresholds and reporting.
Judge what an ISO/IEC 5055 result proves and what it does not, including the absence of organisational certification.
Apply the standard in a realistic scenario, such as acceptance criteria for an outsourced application.
Relate ISO/IEC 5055 to ISO/IEC 25010, ISO/IEC 25023, MITRE CWE, secure coding standards and function point sizing.

Lesson 1 – Origins, purpose and scope

The gap that functional testing leaves

Most quality work in software checks behaviour. Testers run the application and confirm that it does what the requirements say: the right screens appear, the right totals are calculated, the response arrives within a few seconds on the test environment. This is essential work, but it can only find problems that show up in the scenarios someone thought of testing. A large class of serious problems does not show up that way.

Imagine an order system that passes every acceptance test. Inside it, one database query is built by concatenating text typed by the user. A connection to the database is opened in an error path and never closed. A remote pricing service is called once per order line inside a loop. The user interface layer reaches straight into database tables, bypassing the business rules. None of these causes a failed test case on the day of release. Months later they cause a data breach, a slow memory leak that crashes the server at month end, a cloud bill that grows with every customer and a simple change request that takes six weeks because nobody can predict its side effects.

All of these problems live in the structure of the code: how individual statements are written and how components are connected. The property they damage is called structural quality. You cannot measure it well by running the program; you measure it by examining the code itself.

Why a standard was needed

Static analysis tools that examine code have existed for decades, so why was a standard needed? The answer is comparability. Each tool vendor chose its own rules, its own severity scale and its own scoring method. One tool might report thousands of minor style issues while another reported a few dozen serious flaws, and both called the result a "quality score". A buyer could not compare two suppliers, and a manager could not compare two systems, because the numbers meant different things.

CISQ, an industry consortium co-founded in 2010 by OMG and the Software Engineering Institute at Carnegie Mellon University, set out to fix this. Experts from software buyers, system integrators and tool vendors agreed on a list of weaknesses that are severe enough that they should not be present in production code. For each weakness they described exactly how it can be recognised in source code, and they defined how to count the results. If tools implement the same definitions, their counts become comparable and can be used in targets, benchmarks and contracts.

CISQ first published four separate measures through OMG, one each for security, reliability, performance efficiency and maintainability. These were later revised, extended with weaknesses typical of embedded software, and merged into a single specification, ASCQM. OMG then submitted ASCQM to ISO/IEC JTC 1, and it was published as ISO/IEC 5055:2021. CISQ described it as the first ISO standard to measure characteristics such as security and reliability from the internal structure of software rather than from its behaviour in operation.

What is in scope

ISO/IEC 5055 measures a software product, specifically its source code and closely related artefacts such as database access code, schema definitions and configuration that the analysis can read. It is written to be independent of programming language and applies to business applications as well as embedded systems. It defines four measures, each tied to one quality characteristic from the ISO/IEC 25010 product quality model.

What is out of scope

The standard does not assess development processes, team maturity or management systems. It says nothing about whether requirements are correct, whether the user interface is pleasant or whether the software meets legal obligations. It does not replace functional testing, performance testing in production-like environments, penetration testing or architecture review. It covers four of the characteristics in ISO/IEC 25010, not all of them; functional suitability, compatibility and usability (renamed interaction capability in the 2023 edition of ISO/IEC 25010), for example, are not measured. Keeping this narrow scope in mind is the single most important habit when you read an ISO/IEC 5055 result.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 5055 uses a small vocabulary with precise meanings. The terms below are explained in plain language; the standard's own definitions are more formal.

Structural quality – how soundly the software is built internally, judged against good coding and architectural practice. It is the subject of ISO/IEC 5055.
Functional quality – how well the software does what users and requirements expect. It is measured by testing and review, not by this standard.
Quality characteristic – a broad quality area in the ISO/IEC 25010 product quality model. ISO/IEC 5055 covers four: security, reliability, performance efficiency and maintainability.
Weakness – a flaw in code or architecture that can lead to a vulnerability, a failure, wasted resources or costly maintenance. Every weakness in the standard is considered severe enough that it should be removed.
CWE (Common Weakness Enumeration) – the public catalogue of software and hardware weakness types maintained by MITRE. Each ISO/IEC 5055 weakness has a CWE identifier, such as CWE-89 for SQL injection.
Parent and child weakness – CWE arranges weaknesses in hierarchies. A broad parent, such as improper restriction of operations within memory buffer bounds, can have more specific children. The standard uses both levels.
Detection pattern – a precise description of the code elements and relationships that reveal a weakness. One weakness can have several detection patterns because it can appear in different forms.
Knowledge Discovery Metamodel (KDM) – an OMG metamodel, also published as ISO/IEC 19506, for representing the structure of software independently of language. It gives the detection patterns a tool-neutral vocabulary.
Static analysis – examining code without executing it. ISO/IEC 5055 measures are designed to be computed by static analysis tools.
Occurrence – one concrete instance of a weakness found at a specific place in the code, for example one particular query built from user input.
Base measure – the count of weakness occurrences found for one quality characteristic.
Derived measure – a value calculated from base measures and other data, such as weakness density (occurrences per unit of size) or a sigma level.
Weakness density – occurrences divided by a size measure, for example per thousand lines of code or per function point, so that systems of different sizes can be compared.
Conformant tool – a static analysis tool that implements the standard's weaknesses and counting rules. Coverage claims should be checked, not assumed.
False positive – a reported occurrence that turns out, on inspection, not to be a real weakness. Managing false positives is part of every credible measurement programme.

Component-level and system-level weaknesses

Some weaknesses are visible within a single function, method or file. Examples are a return value that is never checked, a resource that is never released or an empty block that silently swallows an error. Others only become visible when a tool follows data and control across components, layers and languages. Examples include user input that passes through several classes before reaching a database query, a presentation layer that calls the data layer directly, or a transaction started in one component that is not handled correctly in another.

CISQ has stressed that the cross-component, or system-level, weaknesses are usually fewer in number but are responsible for a large share of serious incidents and are expensive to fix. This is why ISO/IEC 5055 is meant to be applied to a whole application, with all its tiers and technologies, rather than to isolated files. A tool that only looks at one file at a time can find component-level weaknesses but will miss most system-level ones.

Measurement, not opinion

A good measure is repeatable: two analysts using correctly implemented tools on the same code should obtain the same counts. That is why the standard limits itself to weaknesses that can be detected objectively and that experts agree are severe. Matters of taste, such as naming conventions, brace placement or comment style, are deliberately left out. The aim is a number that a supplier and a customer can both accept, not a review opinion that can be argued about.

Lesson 3 – Structure of the standard

Figure 1 – How the CISQ measures became one OMG specification and then the international standard ISO/IEC 5055.

Figure 1 shows the lineage. Understanding it helps you read older documents: you may find references to separate CISQ security, reliability, performance efficiency or maintainability measures. They are the ancestors of ISO/IEC 5055, which combines and updates them.

The main parts of the document

Without reproducing its text, the standard can be described as having these main parts:

Scope, conformance and normative references, which say what the measures cover and what a tool or user must do to claim that they apply the standard.
Terms, definitions and abbreviations, which fix the meaning of words such as weakness, measure element and detection pattern.
A description of the inputs to measurement and of how the measures are built, including how the analysed software is represented and how occurrences are counted.
Four sets of weakness definitions, one per quality characteristic. Each weakness is described with its CWE reference, the reason it harms the characteristic and its detection patterns.
Calculation rules: how occurrences are added up into one base measure per characteristic across the whole application, plus informative guidance on dividing by size to obtain a density.
Supporting material that explains how the measures relate to ISO/IEC 25010 and how results can be used.

From quality characteristic to counted occurrence

Figure 2 – The layers of an ISO/IEC 5055 measure, from a quality characteristic down to counted occurrences and derived measures.

Figure 2 is the most useful mental model of the standard. Read it from the top. A quality characteristic, such as reliability, comes from ISO/IEC 25010. ISO/IEC 5055 defines one measure for that characteristic. The measure is made up of a list of weaknesses, each with a CWE identifier. Each weakness is recognised through one or more detection patterns. A tool analyses the application, applies the patterns and records every occurrence. The number of occurrences per characteristic is the base measure. Organisations then calculate derived measures, such as density, so that results can be compared over time and across systems.

The authors used the subcharacteristics of each ISO/IEC 25010 characteristic to check coverage. For reliability, for instance, they looked for weaknesses that threaten availability, fault tolerance and recoverability, not only outright crashes. For maintainability they looked at analysability, changeability and testability. This is why each list contains a spread of weakness types rather than many variations of one problem.

The four measures

Measure	What it protects	Typical weaknesses (with example CWE IDs)
Security	Confidentiality, integrity and resistance to attack	SQL injection (CWE-89), cross-site scripting (CWE-79), OS command injection (CWE-78), path traversal (CWE-22), hard-coded credentials (CWE-798), buffer overflow (CWE-119)
Reliability	Availability, fault tolerance and recoverability	NULL pointer dereference (CWE-476), use after free (CWE-416), improper synchronisation between threads (CWE-662), unchecked return values (CWE-252), poor exception handling in transactions
Performance efficiency	Response time and use of computing resources	resources not released (CWE-404), expensive platform calls inside loops (CWE-1050), inefficient data access such as excessive index range scans (CWE-1094), static connections instead of connection pools
Maintainability	Analysability, changeability and testability	dead code (CWE-561), inefficient algorithmic complexity (CWE-407), source files with too many lines of code (CWE-1080), duplicated logic, hard-coded literals, calls that skip architectural layers

The lists are not of equal length. Security and reliability have the longest lists; performance efficiency has the shortest. Some weaknesses belong to more than one measure. A buffer overflow, for example, can crash a program, which harms reliability, and can let an attacker run code, which harms security. When you add up the four lists you therefore count some weaknesses twice. In total the standard draws on well over a hundred CWE entries. MITRE publishes a CWE view, "CISQ Quality Measures (2020)", that groups the weaknesses by characteristic and is a convenient free reference, although it is not a substitute for the standard's detection patterns.

Base and derived measures

The standard's measures are counts. A count on its own is hard to interpret: forty reliability occurrences is alarming in a small service and remarkable in a ten-million-line platform. The usual next step is to normalise. Weakness density divides the count by a size measure. Lines of code are easy to obtain but vary by language and coding style. Function points, especially Automated Function Points (ISO/IEC 19515), measure functional size independently of language and are a better denominator when you compare systems written in different technologies.

CISQ also notes that results can be converted into a sigma level, a term borrowed from Six Sigma quality engineering, where a defect rate is expressed relative to the opportunities for defects. The standard does not prescribe one conversion method, so a sigma figure is only meaningful together with the method behind it. Whatever derived measure you use, record exactly how you calculated it; otherwise two reports that look comparable may not be.

Keep in mind that the measures are indicators rather than absolute values. They count the weaknesses that experts judged most severe, not every possible weakness in each area, so a lower count signals lower risk in that area without proving the absence of problems.

What the standard does not fix

ISO/IEC 5055 defines what to count. It does not set pass marks, define a quality grade or say how many occurrences are acceptable. Thresholds, weightings, trend targets and reporting formats are decisions for the organisation, its customers or its regulators. Do not confuse these with the limits built into a few weaknesses. Weaknesses such as an over-long source file, excessive cyclomatic complexity or too many parameters are only counted above a size or complexity limit; the specification gives a default limit for each and allows a different value to be set before the analysis, so any changed limit must be recorded with the result. The standard does, however, imply a strong expectation: because every weakness in it is severe, the long-term goal is zero occurrences, and the most dangerous security and reliability weaknesses are commonly treated as release blockers.

Lesson 4 – How it works in practice

Using ISO/IEC 5055 well is less about running a tool and more about running a fair, repeatable measurement programme. Figure 3 shows a typical lifecycle.

Figure 3 – The lifecycle of an ISO/IEC 5055 measurement programme, with a fast build loop and a slower review loop.

Step 1 – Define purpose and scope

Start by asking why you are measuring. Common purposes are release gating, supplier acceptance, portfolio comparison, technical due diligence before an acquisition, and tracking the effect of a modernisation project. The purpose decides what you measure and how strictly. Then define the scope precisely: which application, which version or commit, which repositories, which languages and tiers, and which code is excluded. Generated code, third-party libraries and test code are typical exclusion questions. Decide them deliberately and write them down, because changing scope later breaks comparisons.

Step 2 – Select a tool and verify coverage

The standard is applied through static analysis tools, and tools vary widely in what they detect. Before you rely on one, ask the vendor for a coverage statement: which ISO/IEC 5055 weaknesses it detects for each language and framework in your stack, and which it cannot. Pay special attention to system-level weaknesses, which need analysis across components and technologies. CISQ recommends choosing tools it recognises as conformant, but even then coverage differs by language. A test application seeded with known weaknesses is a practical way to check claims.

Step 3 – Configure a full analysis

Analyse the application as a whole: user interface, business logic, data access, database scripts and configuration, built as it would be for production. Missing dependencies or unresolved calls produce blind spots. Record the tool name and version, the rule set, the scope and the date with every result. Without these details a number cannot be reproduced.

Step 4 – Baseline and triage

The first run on an existing system often produces a long list. Do not panic, and do not publish it as a headline figure yet. Review a sample of findings with developers who know the code. Confirm real occurrences, mark false positives with a recorded reason, and look for systematic errors such as a framework the tool does not understand. The cleaned result is your baseline. It tells you where you are, not where you must be tomorrow.

Step 5 – Agree thresholds and targets

Because the standard does not set pass marks, you must. A common and sensible approach has three layers. First, a small set of the most dangerous weaknesses, such as injection flaws and hard-coded credentials, are treated as release blockers with a target of zero. Second, new code must not add occurrences: the count may go down but never up, which is often called a "no new weaknesses" rule. Third, legacy occurrences are reduced over time according to an agreed plan, with density targets per release. Targets should be realistic for the starting point and agreed with the people who will do the work.

Step 6 – Measure continuously

Measurement works best inside the delivery pipeline. Many teams run a fast analysis on every merge request to catch new occurrences while the author still remembers the change, and a complete application analysis on each release candidate to produce the official figures. Results go to developers as specific findings with locations and remediation advice, not just as scores.

Step 7 – Report and act

Report the four base measures, the derived densities and their trends, broken down by characteristic and by component. Show which weaknesses dominate, because a few weakness types usually account for most occurrences. Use the results to plan work: fix the blockers, schedule debt reduction, add coding guidance for frequent weaknesses and train developers on them. Periodically review the programme itself, including scope, tool coverage, false-positive rates and whether the targets still make sense.

Roles and artefacts

Measurement owner – usually a quality, architecture or engineering excellence lead who owns the method, the scope definitions and the reporting.
Development teams – fix weaknesses, triage findings in their code and keep new code clean.
Security and reliability specialists – decide which weaknesses are blockers and review disputed findings in their areas.
Vendor or contract manager – writes ISO/IEC 5055 targets into agreements and handles acceptance decisions with suppliers.
Artefacts – a measurement plan, a tool coverage statement, the baseline report, a false-positive register, release reports and a remediation backlog.

Using results for technical debt

The occurrences counted by ISO/IEC 5055 are a natural basis for estimating technical debt, meaning the future cost created by structural shortcuts. CISQ's separate Automated Technical Debt Measure, published by OMG in 2017, estimates the effort needed to remove the remaining weaknesses found by tools that implement the CISQ quality measures. It is not part of ISO/IEC 5055, and it was built on the earlier CISQ measures that ISO/IEC 5055 later replaced, but because the weakness concepts are shared the two fit together. Present any debt figure as an estimate with its assumptions, not as an exact cost.

Lesson 5 – Assessment, certification and compliance

There is no organisational certificate

ISO/IEC 5055 is a product measurement standard, not a management system standard like ISO 9001 or ISO/IEC 27001. There is no accredited scheme in which a certification body audits an organisation and declares it "ISO/IEC 5055 certified". What exists is a measurement result for a specific version of a specific application, produced with a specific tool and scope on a specific date. Be careful with marketing that suggests otherwise, and do not make such claims yourself.

What a valid claim looks like

A defensible statement names the application and version, the scope analysed and excluded, the tool and its version, the date, the four base measures and any derived measures with their calculation method. For example: "Release 7.3 of the billing platform, all Java and SQL code excluding generated sources, analysed with tool X version Y on 2026-10-01, contained 0 security, 12 reliability, 7 performance efficiency and 140 maintainability occurrences of ISO/IEC 5055 weaknesses." Anyone with the same code, tool and scope should be able to reproduce it.

Tool conformance

The other side of assessment is the tool. A tool vendor may claim that its product implements the ISO/IEC 5055 measures, and CISQ advises buyers to choose technology it has endorsed as conformant. The conformance clause expects an implementation to be automated (no manual counting), objective (the same code gives the same result every time), transparent (it lists all the code, versions and other inputs it used) and verifiable (it documents its assumptions so that a third party can check the calculation). Treat a conformance claim as necessary but not sufficient. Ask for the per-language coverage statement, ask how system-level weaknesses are found, and test the tool on code you know. If two tools give very different counts on the same code, the cause is usually different coverage or different counting of occurrences, and that must be understood before results are compared.

Independent assessment

Organisations sometimes ask an independent party to measure an application, for example before buying a company, accepting a large delivery or settling a dispute. The independent assessor applies the standard with a documented scope and tool and reports results with their limitations. This adds credibility because the party that wrote the code is not the party that measured it.

Compliance uses

ISO/IEC 5055 becomes a compliance matter when a contract, a procurement rule or an internal policy refers to it. Typical clauses require that deliveries contain no occurrences of specified security weaknesses, that densities stay below agreed values, or that counts do not rise between releases. The standard gives these clauses a precise meaning. It is also useful supporting evidence in secure development and supplier assurance programmes, because it shows that code was checked against a published list of severe weaknesses.

Limits you must state

A count of zero means the tool found no occurrences within its coverage and the agreed scope; it does not prove the software is secure or reliable.
Weaknesses outside the four lists, such as business logic flaws, misconfigured cloud services or weak authentication design, are not covered.
Results depend on tool coverage, which varies by language and framework.
Counts can be lowered by narrowing scope or excluding code, so the scope must always travel with the result.
Structural quality is one input to decisions alongside testing, operations data and expert review.

Lesson 6 – Worked example

This lesson follows a fictional company through a realistic first year with ISO/IEC 5055. The numbers are invented for teaching.

The situation

Northwind Freight is a mid-sized logistics company. Its shipment-tracking platform was built by an external supplier and is maintained by that supplier under a three-year contract. The platform has a web front end, Java services, a message queue and a relational database with stored procedures, about 420,000 lines of code in total. Customers complain about outages at the end of each month, and an internal penetration test found an injection flaw. The contract only says that code must be of "good professional quality", which has led to disputes. The new head of engineering, Amira, wants objective criteria before the contract is renewed.

Step 1 – Purpose and scope

Amira defines two purposes: release acceptance for the supplier's deliveries and a reduction of the structural debt that drives outages. The scope is the whole platform: front end, Java services, database scripts and configuration. Generated client code and open-source libraries are excluded, but the integration code that calls them is included. She writes this into a one-page measurement plan.

Step 2 – Tool selection

Northwind shortlists two static analysis tools that claim ISO/IEC 5055 support. Amira asks both vendors for coverage statements for Java, JavaScript and the database's SQL dialect. One tool analyses files separately and cannot follow data from the web layer through the services into stored procedures. The other builds a model of the whole application. Northwind runs both against a small test project seeded with known weaknesses; the second tool finds the cross-layer injection the first one misses. Northwind chooses the second tool and records its version.

Step 3 – Baseline

The first full analysis of release 5.0 reports 46 security, 88 reliability, 35 performance efficiency and 410 maintainability occurrences. Developers from Northwind and the supplier review a sample. They confirm most findings but mark 9 reliability findings as false positives, because the tool misreads a custom retry wrapper. They record the reasons in a false-positive register and report the issue to the vendor. The cleaned baseline is 46, 79, 35 and 410. Northwind also obtains a functional size from automated function point counting, so that densities per function point can be tracked alongside the raw counts.

Step 4 – Reading the baseline

The analysis shows where the pain comes from. Of the reliability occurrences, most are resources that are not released in error paths and unchecked return values in the batch jobs that run at month end, which matches the outage pattern. The security occurrences include several cases of user input reaching SQL statements without neutralisation, including the one found in the penetration test. Most maintainability occurrences sit in two old services with very large, complex methods and duplicated logic. The performance occurrences cluster in a reporting module that queries the database inside loops.

Step 5 – New contract terms

Northwind and the supplier agree new acceptance criteria, shown in Figure 4.

Figure 4 – Northwind's release acceptance decision built on ISO/IEC 5055 results, from blocker weaknesses to the legacy reduction plan.

Blockers: no occurrences of a named list of injection, hard-coded credential and memory-safety weaknesses in any delivered release.
No new occurrences: counts per characteristic in changed components must not rise compared with the previous release, unless a waiver with a reason is agreed.
Legacy reduction: reliability occurrences fall by at least half within a year, starting with the month-end batch jobs; maintainability density in the two old services falls by an agreed percentage per quarter.
Evidence: each delivery comes with the analysis report, tool version, scope statement and updated false-positive register.

Step 6 – Running the programme

The supplier adds a fast analysis to its pipeline so that developers see new findings on each merge request. The official measurement runs on every release candidate. In the first release under the new terms, the security count falls from 46 to 0 after the injection flaws are fixed with parameterised queries. Reliability falls to 51 as the batch jobs are corrected. The month-end outages stop after the second release. Maintainability moves slowly, because the two old services need refactoring, and the team schedules that work over several quarters.

Step 7 – Review after a year

At the annual review Amira finds three lessons. First, a stable scope was essential: one early report looked better only because a module had been left out by mistake, and the scope statement caught it. Second, the false-positive register needed discipline; entries are now reviewed by a second person. Third, the measures did not cover everything: a business logic flaw in the pricing rules was found by testing, not by analysis. Northwind keeps penetration testing and functional testing, and treats ISO/IEC 5055 as one strong, objective input among several. The renewed contract keeps the criteria, with tighter density targets for the next period.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 5055 sits in a family of quality, measurement and secure coding standards. Knowing the neighbours helps you use each for what it does best.

Standard or framework	What it does	Relationship to ISO/IEC 5055
ISO/IEC 25010 (product quality model)	Defines the characteristics and subcharacteristics of software product quality	Supplies the four characteristics that ISO/IEC 5055 measures; 5055 was aligned with the 2011 model, and the four characteristics remain in the 2023 edition
ISO/IEC 25023 (measurement of product quality)	Defines measures for all product quality characteristics, many based on testing and operation	Complementary: 25023 covers behaviour and all characteristics broadly; 5055 adds precise, automatable measures of internal structure for four of them
MITRE CWE and the CWE Top 25	Public catalogue of weakness types and an annual list of the most dangerous ones	Every ISO/IEC 5055 weakness is a CWE entry; CWE is the shared vocabulary, 5055 selects and defines how to count
ISO/IEC 19515 (Automated Function Points)	Counts functional size automatically from code and data structures	Provides a language-independent denominator for weakness density
Secure coding standards (for example SEI CERT, MISRA)	Rules for writing code in specific languages safely	Prevent weaknesses at the source; 5055 measures whether severe weaknesses remain
OWASP Top 10 and ASVS	Awareness list and verification requirements for web application security	Broader security scope, including design and configuration; 5055 counts code-level security weaknesses objectively
ISO/IEC 19506 (KDM)	Language-independent model of software structure	Gives the detection patterns a precise, tool-neutral vocabulary

ISO/IEC 25010 and 25023 in more detail

ISO/IEC 25010 is the quality model: it tells you what quality means for a software product by naming characteristics such as reliability and dividing them into subcharacteristics such as availability and recoverability. It does not tell you how to measure them. ISO/IEC 25023 provides measures for every characteristic, but many of them observe the software's behaviour, for example failure rates during testing or response times under load. ISO/IEC 5055 fills a specific gap: it measures, from the code, the internal weaknesses that are likely to cause poor behaviour later. Used together, the three give you a model, behavioural measures and structural measures.

CWE: shared vocabulary

The CWE catalogue contains many hundreds of weakness types, ranging from very specific to very abstract, and is maintained by MITRE with government sponsorship. ISO/IEC 5055 picks out those that experts judged severe and detectable, and adds detection patterns and counting rules. The yearly CWE Top 25 list ranks weaknesses by how often and how severely they appear in published vulnerabilities, so it reflects attack data. The ISO/IEC 5055 security list covers many of those weaknesses but was chosen by a different method, and the two lists should not be treated as identical.

Process standards

Process models such as CMMI and process assessment standards such as ISO/IEC 33001 look at how an organisation works. ISO/IEC 5055 looks at what it produced. They are complementary: a mature process should, over time, produce code with fewer ISO/IEC 5055 weaknesses, and structural measurement gives process improvement programmes an objective product-side indicator.

CISQ's other specifications

CISQ has produced other measures that use the same approach. Automated Function Points, published as ISO/IEC 19515, measure size. Automated Enhancement Points size both functional and non-functional changes in a release. The Automated Technical Debt Measure converts remaining weaknesses into estimated fix effort. A data protection measure focuses on weaknesses that can expose sensitive data, and work on a resource sustainability measure looks at code that wastes computing resources and energy. These specifications are useful companions, but only what is published in ISO/IEC 5055:2021 is part of the standard you claim to apply.

Common pitfalls and best practices

Pitfalls

Treating zero as proof of security – a clean ISO/IEC 5055 result covers four lists of weaknesses within a tool's coverage. Design flaws, business logic errors and configuration mistakes remain possible.
Comparing results from different tools or scopes – counts depend on tool coverage, version and scope. Compare only results produced the same way, or explain the differences.
Analysing files instead of the application – file-by-file analysis misses system-level weaknesses, which are often the most damaging.
Publishing raw baseline counts as a scorecard – an untriaged first run includes false positives and invites blame. Clean the baseline and explain it before showing it to management.
Using counts without size – raw counts favour small systems. Use densities when comparing systems of different sizes.
Gaming the scope – excluding difficult modules or marking real findings as false positives lowers numbers without improving code. Keep scope statements and false-positive registers under review.
Claiming organisational certification – there is no accredited ISO/IEC 5055 certificate for companies; such claims mislead customers.

Best practices

Start with purpose – decide whether you measure for acceptance, improvement, comparison or due diligence, and design the programme around it.
Verify tool coverage – obtain per-language coverage statements and test them on seeded code before trusting results.
Record the measurement context – keep application version, scope, tool version and date with every result so it can be reproduced.
Stop new weaknesses first – a "no new occurrences" rule in the pipeline prevents the problem from growing while legacy debt is reduced.
Treat the worst weaknesses as blockers – agree a short list of security and reliability weaknesses that must be fixed before release.
Report trends by characteristic and component – trends and hot spots guide action better than a single overall score.
Combine with other evidence – use structural measures alongside testing, security reviews and operational data.
Train developers on frequent weaknesses – the same few weakness types usually dominate, and targeted training prevents them.

Summary and key takeaways

ISO/IEC 5055:2021 defines automated, source-code-based measures of structural quality for security, reliability, performance efficiency and maintainability.
It grew out of CISQ's work, became the OMG ASCQM specification and was published by ISO and IEC through JTC 1 in 2021.
Each measure is a list of severe weaknesses identified by CWE entries and recognised through precise detection patterns.
The base measure is a count of occurrences per characteristic; densities and sigma levels make results comparable.
The standard defines what to count, not what is acceptable: thresholds and targets are set by organisations and contracts.
Results are only meaningful with their context: application version, scope, tool, tool version and date.
There is no organisational certification; a claim is a reproducible measurement of a specific release.
It complements ISO/IEC 25010 and 25023, CWE, secure coding standards and testing rather than replacing them.

Reflection questions

Pick an application you work on. Which of the four ISO/IEC 5055 characteristics causes the most real-world pain today, and what evidence do you have?
If you had to write ISO/IEC 5055 acceptance criteria for a supplier tomorrow, which weaknesses would you make blockers and why?
How would you define the measurement scope of your main system, and which exclusions could someone use to make the numbers look better?
Your team's first analysis reports hundreds of maintainability occurrences. How would you present this to management without causing blame or panic?
Which risks in your software would remain invisible to ISO/IEC 5055, and which other practices cover them?