Vulnerabilities and Threats

[jasc76]

Was there any thought about including the ability to link the 27001 standard threats and vulnerabilities to Assets and risks

[coolstartnow]

Thanks for raising this — worth clarifying, because there are actually two different things this could mean.

If you mean shipping the ISO 27001/27005 threat and vulnerability catalogue itself: that's deliberately not included, same reasoning as the control texts (see the Standards & Legal Notices on the website) — those lists are part of copyrighted ISO material, not something this project redistributes.

If you mean the ability to link threats/vulnerabilities to assets and risks as a structural feature: that already exists in a specific form — every risk has free-text threat and vulnerability fields (server/db/riskStore.js). That was a deliberate choice, not an oversight: free text means no catalogue to maintain, no migration every time a new threat type shows up, and everyone can describe things in whatever level of detail fits their context.

What it doesn't give you is a reusable, structured library — pick "Threat X" once, attach it to multiple assets and risks, then ask "which assets are exposed to Threat X". That's a real capability gap if you need it, but it comes with an ongoing maintenance cost (a taxonomy someone has to keep current) that free text avoids entirely.

Could you say more about what you're trying to do — is it the cross-referencing/reporting angle, or something else? That would help me judge whether it's worth the added complexity.

[jasc76]

Of course you cant ship the texts, this would be up to the user.

I know there are the text fields. But often its the same stuff so linking is much faster than writing the same things over and over again. THere is also no migration, because when you add threats/vulnerabilities to the catalog these are new and can then be linked, Also your AI argument that when somethings changes its more work using linked items is not valid, because with linked items you change the item once centrally and all is updated. With text fields one would have to scan through all entries and edit a text field. Thats much more work

Well its just ease of work to have standard threats and vulnerabilities and link them. Often these are the same, so why use text...

[coolstartnow]

Fair point on the maintenance argument from the user's side — a centrally-edited catalogue is less work to keep in sync than scanning free-text fields once something changes.

But there's a cost on my side that argument doesn't account for: this project supports three storage backends (JSON files, and SQLite/MariaDB/Postgres via Knex — see server/db/knexDatabase.js). A new catalogue wouldn't just be "one more table" — it needs a schema definition for the Knex backends, a corresponding JSON-store implementation, API routes, RBAC checks, a link-picker UI, and translations, and all of that has to be kept in sync and migrated whenever the schema changes. So the maintenance burden doesn't disappear, it moves from "user edits free text" to "maintainer keeps a schema in sync across three database engines" — which is a bigger commitment than it might look like from the outside.

Free text is enough for what I need right now, and I can't currently commit to if or when a structured, linkable catalogue would get built. I'll leave this issue open as a tracked idea rather than closing it.