Framework core concepts

Capabilities drive secure products

What's so special about capabilities that we've built an entire framework around them? Read on!


axiom | ˈaksɪəm |


A statement or proposition which is regarded as being established, accepted, or self-evidently true.

The quality outcomes axiom

This framework introduces the quality outcomes axiom:

A process diagram showing the quality outcomes axiom

Your delivery organisation's capabilities lead to actions, which lead to product quality, which delivers customer value and leads to business outcomes.

Put more simply, the things you do lead to the outcomes you get. This is axiomatic (or: just plain obvious). Accepting this means that capabilities are the start of all aspects of your software products' quality and, ultimately, of the value your customers get from them and the business outcomes they bring.

Not just businesses...

Non-commercial outcomes if you're a community software project. Gaining more use and a happier user base are good outcomes of a higher-quality community project!

An example security capability

Let's make this less abstract with an example of one of the PSCF's security capabilities. In this case, an essential technical capability to meet the requirements of NIST SSDF PW.5.

PSCF-SPI-SCP: Secure Coding Practices

The capability to define, understand and apply secure coding practices to the creation of source code for use in the organisation's products

As you can predict, having a high level of capability here leads to the activity of writing more secure code for your software products. This makes them higher quality from a security point of view, leading to more customer value (your customers do value security!) and better business outcomes.

What if your organisation isn't very capable at this?

Of course, if you appraise your organisation and score low for this capability because of a lack of understanding, a lack of good guidance, or your software developers aren't given enough time to write secure code, just quick hacky code, then the security quality won't be in your products. Leading to your customers potentially seeing other customers' data or having their data stolen. This isn't leading to the kind of outcomes you want.

We've mentioned quality a lot when talking about software product security, but haven't defined exactly what quality is in the PSCF yet. Let's do that now.

Security requirements not security opinions