| Production Defaults |
In any case ThreatSea relies on external sources like configuration variables etc. to determine its behaviour, it should either check if the external input is complete and correct and file an error if not, or default to production values. Defaults shall never be development values. In either case, precautions have to be taken that a safe state is reached. Counterexamples are connecting to the production backend or database from a test system or having the system endlessly trying to connect to an unconfigured database. |
Following the architectural principle of fail-safe defaults |
Decided |
17 Dec 2024 |
| Development or Debug Code |
The production build of ThreatSea shall never contain code only meant to run in development environments but not in production. On the same note, ThreatSea code should behave the same way in all environments. This is at least mandatory for preproduction and production. Deviating behaviour shall never be controlled by side effects (e.g. reading NODE_ENV) but explicitely (e.g. by dedicated environment variables like LOG_LEVEL). |
To guarantee tests cover production code, reduce complexity and attack surface, avoid intransparent dependencies and have fail-safe defaults. |
Decided |
17 Dec 2024 |
| Translations |
Each translation has to be maintained at one unique location. Translations must be structured in the following file structure: de common methodology_terms.de.js → includes 4x6 specific terminology like attack point names general.de.js → includes general terminology like "OK", "Abbrechen", "Speichern" additional required files, e.g. is_classification.de.js for information classification scheme pages apply-measure-dialog-page.de.json → specific terminology required for the "Apply Measure" dialog en common ... pages ... |
Avoiding duplicate translations |
Decided |
17 Feb 2025 |