These are currently stored in the database and toggled by flipping a bit column in the models table.

Could add a quick widget for admins to allow toggling this on arbitrary models.

We've had suggestions from multiple teams to bring back trust boundaries to Gram.

• A way to show e.g. same machine,. same network.
• Mimic threats/controls on multiple components

A basic implementation would be to add a new rectangular component that can be resized and labeled.

• Allow TM owners to add/"invite" others to their threat model & collaborate on it
• Would avoid issues with teams collaborating

For more complete threat documentation in a TM, we should consider adding threat actors as part of the threat creation process.

It is super useful to have links to our docs/channels in the tutorial, however they don't make sense outside of Klarna. Ideally we could still keep them somehow, by being able to customize the text.

From user feedback. It would be useful if the standard undo/redo functionality existed. This would help against accidentally deleting components.

There might be an easy way to implement this using redux, since that's very much what the framework was originally built for.

Given that Gram is collaborative over websocket, it might be a bit tricky to accomplish.

For inspiration:
https://redux.js.org/usage/implementing-undo-history

Was accidentally removed while stripping away Klarna specific code

Gram was initially mainly a "lightmode" implementation in Klarna Pink / White. Then we added MUI and made an attempt to make things more "darkmode". We ended up somewhere halfway.

Finish the darkmode/lightmode implementation.

Question from one of our security leads:

Have you looked into if it would be possible to define “reviewer groups” in gram instead of requesting reviews from individuals - similar to how you can request a review from SecDev. The idea of the SecChamps from my domain and me was pretty much that it would be great if our domain could just select something like “ Threat Model Reviewers” and we would in the background be linked to that group and one of us that is available can pick up the threat model review. Currently the reviews rely on individuals being selected and redistributing them requires manual work.

To be able to demo the feature.

Holding the keyboard button for panning (space) while at the same time the toolbar pan is active works, but when the keyboard button is released it goes back to a non-panning mode without updating the toolbar mode.

If you import from an old model that has accepted suggestions, the suggestions will reappear again.

The system should be smarter and recognize suggestions from the previous model.

This otherwise messes with the stats and confuses the user.

Right panel improvements from feedback:

• Indicate empty with a nice icon or text when no component is selected
• Indicate no threats/controls/suggestions with some icon or text saying that the user should add threats/controls
• Hide long descriptions
• Sorting and filtering of threats and controls
• Add animation when a suggestion is generated to draw attention

Per default all the current plugins are installed into the api backend and part of the top-level package-lock.json.

Need to find a cleaner way to keep plugins optional and not installed per default.

See picture above, stack user icons better in the diagram views.

Describe this tool is intended to be run and set expectations on what it can do.

It was designed with certain things in place, certain shortcuts could be taken because we never expect more than X users, etc.

Would be helpful to e.g. link to best practices or how-to documents.

In Gram, it would be useful if we could rank and prioritize threats by their severity.

Define some sort of gradient scale.

This repo is the "base" Gram and the idea is that an implement organization should be able to customize it to their liking by adding plugins.

There is already functionality currently in the form of "packs" that is bootstrapped into the application at runtime. This allows for supplying different provider classes which are used to supply e.g. authentication, system/user lookups, suggestions, notification templates, etc.

Besides forking or just running it without custom code (i.e. pull docker, supply env), I would like to support the following setup:

• Repo that has:
  • Folders with custom plugins/packs (package.json with Gram installed to access types?)
  • A bootstrap/configuration-as-code file that essentially does bootstrap.ts plus loads config. The more exposed to the api here the more an org can customize.
  • Dockerfile extending base Gram and adding in the custom code.

Currently there are two menu items that at Klarna were hardcoded to external sites: Feedback and Docs.

Make menu items configurable or supplied via a Provider.

It might also make sense to be able to rename links to something different (e.g. teams might be something else depending on the grouping).

As MVP: have a system to add links to the menu via a provider.

Should have static ids, e.g.

Spoofing: /stride/threat/spoofing
Tampering: /stride/threat/tampering
Repudiation: /stride/threat/repudiation
Information Disclosure: /stride/threat/information-disclosure
Denial of Service: /stride/threat/denial-of-service
Elevation of Privilege: /stride/threat/elevation-of-privilege

Can copy from Klarna origin.

Currently there is an incomplete link to my team's slack channel in one of the first views.

See #23

Instead of trying to conform to locale, which doesn't seem to work well.

https://github.com/klarna-incubator/gram/blob/master/app/src/components/elements/DateLabel.js#L9

Lots of Klarna-specific stuff has been cut away. As a first step we need to get it to run.

Look into adding validation library that covers both use cases

DoD:

• Use a known library for validating data (e.g. Joi)

Makes for a cool demo 😎

• Authentication
• System Mapping (repo -> system)
• System Properties (Repo URL, stargazers? other interesting stats)
• Team Mapping (Org/Installation -> Team)
• Authorization (public repo -> read access, private repo -> full authz if collaborator)
• Documentation

Frontend (./app):

• npm test
• npm run lint
• npm run snyk

Backend (./api):

• npm test
• npm run lint
• npm run snyk

https://nx.dev/recipes/other/resolve-circular-dependencies

Exploring adding comments to the Gram diagram as a way for teams and reviewers to add further description to their diagram.

For inspiration, we could try doing something like Miro does it:

Currently the search simply returns the first 10 results.

To make it a bit better it should have:

• Pagination 
• Add some description of how many results are appearing

The case where a threat model is not attached to a system should be handled smoother. It works ok, but the backend throws a lot of errors as fetches are made against the "null" systemID (00000000-0000-0000-0000-000000000000).

gram-gram-1      | [2022-11-28T21:47:25.012] [INFO] auditHttp - GET /api/v1/reviews/dcd4d328-f8dc-489c-b46e-286e58ec2d72 18ms
gram-gram-1      | [2022-11-28T21:47:25.021] [WARN] GithubAuthzProvider - got invalid systemID: SM4SM4{M4Sm4SO4SM>SM4SM4SM4
gram-gram-1      | [2022-11-28T21:47:25.022] [WARN] app - AuthzError: User Tethik is unauthorized for system systemId: 00000000-0000-0000-0000-000000000000. () vs required: (read)
gram-gram-1      |     at new AuthzError (/home/gram/build/src/auth/AuthzError.js:8:28)
gram-gram-1      |     at /home/gram/build/src/auth/authorization.js:199:31
gram-gram-1      |     at step (/home/gram/node_modules/tslib/tslib.js:144:27)
gram-gram-1      |     at Object.next (/home/gram/node_modules/tslib/tslib.js:125:57)
gram-gram-1      |     at fulfilled (/home/gram/node_modules/tslib/tslib.js:115:62)
gram-gram-1      | [2022-11-28T21:47:25.027] [INFO] auditHttp - GET /api/v1/systems/00000000-0000-0000-0000-000000000000 24ms
gram-gram-1      | [2022-11-28T21:47:25.065] [INFO] auditHttp - GET /api/v1/models/dcd4d328-f8dc-489c-b46e-286e58ec2d72/threats 34ms
gram-gram-1      | [2022-11-28T21:47:25.069] [INFO] auditHttp - GET /api/v1/models/dcd4d328-f8dc-489c-b46e-286e58ec2d72/controls 38ms
gram-gram-1      | [2022-11-28T21:47:25.077] [INFO] auditHttp - GET /api/v1/models/dcd4d328-f8dc-489c-b46e-286e58ec2d72/mitigations 24ms
gram-gram-1      | [2022-11-28T21:47:25.242] [ERROR] SystemPropertyHandler - SystemPropertyProvider github errored while providing context TypeError: Cannot read properties of null (reading 'language')
gram-gram-1      |     at GithubSystemPropertyProvider.<anonymous> (/home/gram/build/src/packs/github/GithubSystemPropertyProvider.js:67:49)
gram-gram-1      |     at step (/home/gram/node_modules/tslib/tslib.js:144:27)
gram-gram-1      |     at Object.next (/home/gram/node_modules/tslib/tslib.js:125:57)
gram-gram-1      |     at fulfilled (/home/gram/node_modules/tslib/tslib.js:115:62)

To avoid having to maintain two repositories, the internal Klarna repository will have to reintegrate back with this version when everything is done.

We'll treat this as the new version 3.0.0 of Gram, while the internal Klarna version will remain on 2.x.y until this happens.

One suggestion is to add functionality to allow for categorizing/labeling dataflows, similar to what you can do in OWASP Threat Dragon. 

This would make it easier to model encrypted/non-encrypted flows, as well as the type of data flowing (PII, credit card details).

It would be nice if we could document authentication attached to any data flow, to see how they change as data travels through a system, and potentially spot elevation of privilege issues.

Labeling we're interested in:

• Encrypted or not?
• authentication?
• Protocol?
• Sensitivity of transferred data?

To ensure people do not use the demo instance and expect their data to be safe.

Could be useful otherwise as a way to communicate warnings/deployment notices.

• Threats and controls which are frequently used should share the same id. It would also help cross-component sharing of threats and controls.

• Suggestions currently use static ids already 

• Having common ids for threats would allow easier semantic extraction of data (rather than full-text-search to understand where threats re-appear)

Internal Gram works using SSO Authentication, which has been cut out from this codebase.

Auth is already somewhat abstracted using an AuthProvider interface that can be implemented and provided in a pack.

However the frontend logic is pretty hardcoded and expects to redirect somewhere. Starting the app currently crashes on first page.

Some ideas for possible providers:

• github/oauth (less frontend work if we can just reuse similar redirect logic)
• username/password (less dependent on external)

As per Service Rulebook we ought to supply OpenAPI documentation for our service. Currently we have no dependents planned, so we can likely wait with doing it. However some teams have expressed an interest in consuming our API, so it could be relevant in the future.

Ideally it would be something that can be automatically generated, perhaps something that can be considered with #44 for a more general refactor of the API backend.

Works in Chrome.

Investigate why these domains are called for icons, shouldnt they be built in?

i.e. we use a different auth provider for service-to-service auth that should not be exposed to the user (API used by another service).

In Gram, it would be useful if we could document how well a control mitigates a threat. 

Values: 
Less efficient / efficient / very efficient

Alternatively:
No mitigation / Partially mitigates / Fully mitigates

Would be good to have an easy template to use when creating a plugin. Encountered some issues while migrating our internal plugins that have tests due to ts/jest.