ISO 5055 standard explained. Is your software rock solid, efficient, and safe?

Apr 6, 2021 | Digital Transformation ISO 5055 standard explained. Is your software rock solid, efficient, and safe?

What is ISO 5055

Extensive research shows that 90% of software production issues are caused by just 8% of the software flaws – flaws in the architecture*. Not surprisingly, they also are the hardest to find.

The new ISO 5055 standard (ISO/IEC 5055) addresses this challenge by providing engineering rules for finding and preventing those critical flaws. The set of rules is used to assess the internals of software systems on four business-critical factors – Security, Reliability, Maintainability, Performance Efficiency.

These factors determine how trustworthy, dependable, and resilient a software system will be.

ISO 5055 fills massive gap in standards

Prior international standards did not describe how to assess software for severe structural weaknesses. That is akin to evaluating a house by its appearance, without checking the internals for wood rot.

Prior standards focused on symptoms and offered no clues for the underlying causes. For example, they specify Reliability as a software system characteristic, measured in downtime, such as 2 days per year. When the downtime is worse, you know that you have a reliability issue. But you do not know what in the system is causing the problem.

In contrast, the ISO 5055 rules cover how to identify critical structural weaknesses, such as poor error handling or missing timeouts. So that they can be eliminated before they cause operational problems.

Severe Weaknesses

ISO 5055 zeros in on the most severe issues at both the architectural and component level and provides for a full evaluation of the factors determining a system’s behavior.

One such severe architectural weakness is allowing a path from the user interface directly to the database without passing through validation routines. It is known as ‘Ban Unintended Paths’ that violate safety and data protection controls.

Another example is ‘Improper Resource Shutdown or Release’ – a reliability weakness that can result in frozen customer-facing systems during critical business hours.

Over the last 12 years 2,000+ practitioners from Global 2,000 IT departments, IT services and software vendors, experts from the Software Engineering Institute of Carnegie Mellon University and MIT fellows, and industry standardization consortia, such as CISQ, OMG, Mitre have sorted through a wide range of structural weaknesses in software. They identified the most dangerous ones for inclusion in the ISO 5055 rules, where ‘dangerous’ means that a weakness has to be removed from the software to avoid damaging business operations or excessive IT costs.

A key stipulation of ISO 5055 is that the search for severe weaknesses must be in context. It must be conducted across the entire technology stack of a software system and factor in all interdependencies.

bad-system-example

Analyzing a single software component in isolation, without understanding its context, can itself become dangerous. Going back to the house analogy, it is much like inspecting every brick of a house without looking at how the bricks support each other.

Is your software rock solid, efficient, and safe?

ISO 5055 provides rules to assess whether critical software is trustworthy, dependable, and resilient.

Financial institutions, governments, telecoms, manufacturers, system integrators, and others can leverage ISO 5055 to avoid disruptions, reputational damage, or excessive IT costs.

They can also use the widely accepted standard to show objectively the structural condition of critical systems to regulators, boards, or stakeholders. For example:

  • Regulated banks, required to certify their level of risk to the financial system, can demonstrate the resiliency and security of their core custom-build software systems.
  • Government policies can include standard-based provisions for the structural resiliency of their software supply chains.
  • Manufacturers, whose products affect human life or well-being, can demonstrate the structural safety and reliability of the software permeating their products.
  • System Integrators, who compete to maintain or modernize business-critical applications, can show in objective manner that the software they deliver is structurally sound.

Automatic Detection of non-compliance with ISO 5055 rules

Analyzing software applications and systems in their entirety against ISO 5055 is expected to become the norm in vendor acceptance, application modernization, and quality assurance processes.

The standard defines the rules in a way that allows for automatic detection of the severe weaknesses. Third party software analysis platforms that fully cover the ISO 5055 rules will be able find, report, and measure ISO 5055 weaknesses across the entire technology stack and all its interconnections.

The first such platform to fully cover the standard is the CAST ‘MRI for Software’, with its unique ability to understand the architecture, and track manipulation and access to data all the way from user entry to the database. It performs automatic, full-system analysis of all data structures and code components, and reverse engineers all their interdependencies.

ISO-5055-DB

 

In addition, its Recommendation Engine provides action plans describing which weaknesses to address first to help organizations reach their ISO 5055 score objectives with the least amount of effort.

It provides the shortest path for their software to become rock solid, more efficient, and safer.

ISO-5055-Remediation

* References:

- Li, et al. Characteristics of multiple component defects and architectural hotspots: A large system case study. Empirical Software Engineering, 16 (5), 667‐7029.
- Leszak, M., et al. A case study of root cause defect analysis. Proceedings of the 22nd Conference on Software Engineering. Los Alamitos, CA: IEEE Computer Society, 428-437.
- Kristiansen. Defect Analysis and Costs in the IT Industry. NTNU
- Stoley, R . How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems. Object Management Group and Consortia for Information & Software Quality
- Software quality, Wikipedia