It's my understanding that a missed hardening opportunity is less important to be fixed than a security flaw, but what criteria does one use to decide what to classify something that is wrong with a secure system?
It is always risk that defines that criteria.
What's the likelihood of the problem being exploited, what are the mitigations in place to prevent or limit the impact, and what are the impacts of a successful exploitation?
Once those are defined, you can classify what's wrong with a system and rank them in order or priority, regardless of the type of problem (hardening, 0-day, patches, flaws, etc.).
A line in the sand cannot be drawn where you can absolutely determine which side you are on, but oftentimes it will be obvious. For example, suppose you live with your mom and don't want her to find your weed stash:
- Hiding your stash in the kitchen cupboard = security flaw.
- Hiding your stash in your guitar case under your bed = hardening opportunity.
But sometimes it isn't so obvious:
- Storing user passwords in your DB in plain text = security flaw.
- Encrypting user passwords in your DB = hardening opportunity.
- Hashing user passwords in your DB with SHA1 = hardening opportunity.
But is storing user passwords in plain text really a security flaw? I think one could easily argue that it isn't, if your DB server is well secured.