Merge main into merge_to_eclipse-score (#13)

Erikhu1 · LucaFgr · halnasri · aschemmel-tech · commit f61e53be2bba · 2025-11-26T13:04:09.000+01:00
* update to trudag v2025.10.22 (#4) * update to trudag v2025.10.22 * upgrade pip * upgrade pip in test_publication workflow * pip install requests * TT changes documentation (#7) * answer checklist TT-CHANGES * update TSF/README * add AOU-30 * steps 2-12 * mean of the scores * library -> project * fix typo * additional SMEs * fix comprise typo * nlohmann/json triage process * add JLS-34 to TA_UPDATES context * Reworked the README file for references and validators (#6) * extended TimeVaryingWebReference doc * added validator info to website and project_website reference * Updated readme for all references up to ListOfTestCases * Again reworked the references readme * extended documentation for validators * cosmetic change * cosmetic changes * small fix in TimeVaryingWebReference * Update .dotstop_extensions/README.md Co-authored-by: halnasri <hatem.alnasri@d-fine.com> Signed-off-by: Luca Füger <luca.fueger@d-fine.com> * Added : to expected configuration * Update .dotstop_extensions/README.md Co-authored-by: halnasri <hatem.alnasri@d-fine.com> Signed-off-by: Luca Füger <luca.fueger@d-fine.com> * validator addition * Added combinator trudag remark * added database to README * removed : * Update .dotstop_extensions/README.md Co-authored-by: Erik Hu <erik.hu@d-fine.com> Signed-off-by: Luca Füger <luca.fueger@d-fine.com> --------- Signed-off-by: Luca Füger <luca.fueger@d-fine.com> Co-authored-by: halnasri <hatem.alnasri@d-fine.com> Co-authored-by: Erik Hu <erik.hu@d-fine.com> * link TA-BEHAVIOURS to JLS-27 (#9) * Erikhu1 tt changes documentation (#10) * answer checklist TT-CHANGES * update TSF/README * add AOU-30 * steps 2-12 * mean of the scores * library -> project * fix typo * additional SMEs * fix comprise typo * nlohmann/json triage process * add JLS-34 to TA_UPDATES context * replace XYZ and add disclaimer * update TT_CHANGES context files * update TA_UPDATES context * clean up TA_FIXES context --------- Signed-off-by: Erik Hu <erik.hu@d-fine.com> --------- Signed-off-by: Luca Füger <luca.fueger@d-fine.com> Signed-off-by: Erik Hu <erik.hu@d-fine.com> Co-authored-by: Luca Füger <luca.fueger@d-fine.com> Co-authored-by: halnasri <hatem.alnasri@d-fine.com>
diff --git a/.dotstop.dot b/.dotstop.dot
@@ -376,6 +376,7 @@ digraph G {
 "TA-BEHAVIOURS" -> "JLEX-01" [sha="8cd931ef61b7012140344adf54469e943bfc690ee54f12db12777464880061db"];
 "TA-BEHAVIOURS" -> "JLEX-02" [sha=cb26451e31a56b1eb51a4d45283ba4a7c6e898efbd045b59cba10d3c6aa093de];
 "TA-BEHAVIOURS" -> "JLS-03" [sha=cf9211c07452914cb2d0b455f859b26cb2724423eae5187e8cbfdff06d1b5ba3];
+"TA-BEHAVIOURS" -> "JLS-27" [sha="880ec996ed026258b58299c356aab7d02652ae55cbf1f98494e2a7770fd96275"];
 "TA-CONFIDENCE" -> "JLS-08" [sha="506164051180023c8533ea1f6dedf1bad894c3ee6020ff16b002e33b109c2791"];
 "TA-CONFIDENCE" -> "JLS-09" [sha="80bbde95fc14f89acf3dad10b3831bc751943fe4a1d79d5cbf4702416c27530f"];
 "TA-CONFIDENCE" -> "JLS-20" [sha="1bfd214ab8186a3c095262ae503451b8d71ada8db5b13ecc7b906739a05bc102"];
diff --git a/TSF/trustable/assertions/TA-ANALYSIS_CONTEXT.md b/TSF/trustable/assertions/TA-ANALYSIS_CONTEXT.md
@@ -3,10 +3,12 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
 This assertion is satisfied to the extent that test data, and data collected
-from monitoring of deployed versions of XYZ, has been analysed, and the results
+from monitoring of deployed versions of nlohmann/json, has been analysed, and the results
 used to inform the refinement of Expectations and risk analysis.
 
 The extent of the analysis is with sufficient precision to confirm that:
diff --git a/TSF/trustable/assertions/TA-BEHAVIOURS_CONTEXT.md b/TSF/trustable/assertions/TA-BEHAVIOURS_CONTEXT.md
@@ -3,16 +3,18 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 Although it is practically impossible to specify all of the necessary behaviours
 and required properties for complex software, we must clearly specify the most
 important of these (e.g. where harm could result if given criteria are not met),
-and verify that these are correctly provided by XYZ.
+and verify that these are correctly provided by nlohmann/json.
 
 **Guidance**
 
 This assertion is satisfied to the extent that we have:
 
-- Determined which Behaviours are critical for consumers of XYZ and recorded
+- Determined which Behaviours are critical for consumers of nlohmann/json and recorded
   them as Expectations.
 - Verified these Behaviours are achieved.
 
diff --git a/TSF/trustable/assertions/TA-CONFIDENCE_CONTEXT.md b/TSF/trustable/assertions/TA-CONFIDENCE_CONTEXT.md
@@ -3,6 +3,8 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
 To quantify confidence, either a subjective assessment or a statistical argument must be presented for each statement and then systematically and repeatably aggregated to assess whether the final deliverable is fit for purpose.
diff --git a/TSF/trustable/assertions/TA-CONSTRAINTS_CONTEXT.md b/TSF/trustable/assertions/TA-CONSTRAINTS_CONTEXT.md
@@ -3,6 +3,8 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
 Constraints on reuse, reconfiguration, modification, and deployment are
diff --git a/TSF/trustable/assertions/TA-DATA_CONTEXT.md b/TSF/trustable/assertions/TA-DATA_CONTEXT.md
@@ -3,6 +3,8 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
 This assertion is satisfied if results from all tests and monitored deployments are captured accurately, ensuring:
diff --git a/TSF/trustable/assertions/TA-FIXES_CONTEXT.md b/TSF/trustable/assertions/TA-FIXES_CONTEXT.md
@@ -3,14 +3,16 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
-This assertion is satisfied to the extent that we have identified, triaged, and applied fixes or mitigations to faults in XYZ, as well as to bugs and publicly disclosed vulnerabilities identified in upstream dependencies.
+This assertion is satisfied to the extent that we have identified, triaged, and applied fixes or mitigations to faults in nlohmann/json, as well as to bugs and publicly disclosed vulnerabilities identified in upstream dependencies.
 
-Confidence can be improved by assessing known faults, bugs, and vulnerabilities to establish their relevance and impact for XYZ.
+Confidence can be improved by assessing known faults, bugs, and vulnerabilities to establish their relevance and impact for nlohmann/json.
 An important aspect is documenting how issues are discovered and tracked, including identifying additional Misbehaviours (TA-MISBEHAVIOURS) that may require immediate mitigation measures (including recalls), and how such issues are communicated to users.
 
-In principle, this analysis should include not only the code in XYZ but also its dependencies (all the way down) and the tools and data used to construct the release.
+In principle, this analysis should include not only the code in nlohmann/json but also its dependencies (all the way down) and the tools and data used to construct the release.
 In practice, however, the cost/benefit of this work must be weighed against:
 
 - the volume and quality of available bug and vulnerability reports
@@ -38,26 +40,26 @@ As part of ongoing monitoring, the rate of incoming, resolved, and rejected issu
 - List of outstanding known vulnerabilities still not fixed, with triage/prioritisation based
   on severity/relevance/impact
   - **Answer**: Provided in JLS-30, JLS-33 and AOU-29
-- List of XYZ component versions, showing where a newer version exists upstream
+- List of nlohmann/json component versions, showing where a newer version exists upstream
   - **Answer**: Not relevant since nlohmann/json has no external components, as stated in JLS-34
 - List of component version updates since last release
   - **Answer**: Not relevant as nlohmann/json has no external components, as stated in JLS-34
 - List of fixes applied to developed code since last release
   - **Answer**: Provided in JLS-29
 - List of fixes for developed code that are outstanding, not applied yet
   - **Answer**: Provided in JLS-11
-- List of XYZ faults outstanding (O)
+- List of nlohmann/json faults outstanding (O)
   - **Answer**: Provided in JLS-11
-- List of XYZ faults fixed since last release (F)
+- List of nlohmann/json faults fixed since last release (F)
   - **Answer**: Provided in JLS-29
-- List of XYZ faults mitigated since last release (M)
+- List of nlohmann/json faults mitigated since last release (M)
   - **Answer**: Provided in JLS-29
 
 **Confidence scoring**
 
 Confidence scoring for TA-FIXES can be based on
 
-- some function of [O, F, M] for XYZ
+- some function of [O, F, M] for nlohmann/json
 - number of outstanding relevant bugs from components
 - bug triage results, accounting for undiscovered bugs
 - number of outstanding known vulnerabilities
@@ -70,35 +72,35 @@ Each iteration, we should improve the algorithm based on measurements
 
 **Checklist**
 
-- How many faults have we identified in XYZ?
-  - **Answer**: None that are relevant for S-CORE's use case of the library.
+- How many faults have we identified in nlohmann/json?
+  - **Answer**: 58, but none are relevant for S-CORE's use case of the library (see JLS-11).
 - How many unknown faults remain to be found, based on the number that have
   been processed so far?
   - **Answer**: It is unlikely that there are unknown faults relevant to S-CORE.
 - Is there any possibility that people could be motivated to manipulate the
   lists (e.g. bug bonus or pressure to close).
-  - **Answer**: Unlikely, since the project is entirely open source.
+  - **Answer**: It is unlikely that people would be motivated to manipulate the lists in nlohmann/json. The nlohmann/json project has no bug bounties, and since it is open source, third party individuals suggest fixes with no pressure/incentive to manipulate unfixed issues.
 - How many faults may be unrecorded (or incorrectly closed, or downplayed)?
-  - **Answer**: Few or none, considering the wide use of the nlohmann/json library.
+  - **Answer**: Few or none, considering the wide use of the nlohmann/json library (see JLS-05).
 - How do we collect lists of bugs and known vulnerabilities from components?
   - **Answer**: We pull the list from the issues reported to nlohmann/json labelled as bug and are currently open or were opened since the last release. This list is then stored using GitHub, thereby enabling a traceability of the list.
 - How (and how often) do we check these lists for relevant bugs and known vulnerabilities?
   - **Answer**: Whenever we generate the documentation, the list is pulled. If there is an issue previously unrecorded, then the maintainer is encouraged by the change of the trustable score to check the relevance of the issue.
 - How confident can we be that the lists are honestly maintained?
-  - **Answer**: Very confident, since the authors of the issues in the list mainly comprise of independent downstream users.
+  - **Answer**: Very confident, since the authors of the issues in the list mainly comprise independent downstream users.
 - Could some participants have incentives to manipulate information?
   - **Answer**: No such incentives have been identified.
 - How confident are we that the lists are comprehensive?
-  - **Answer**: Fairly confident, considering the wide use of the library and that downstream users are likely to report discovered bugs.
+  - **Answer**: Fairly confident, considering the wide use of the library (see JLS-05) and that downstream users are likely to report discovered bugs.
 - Could there be whole categories of bugs/vulnerabilities still undiscovered?
-  - **Answer**: Unlikely, considering the wide use of the library and that downstream users are likely to report discovered bugs.
+  - **Answer**: Unlikely, considering the wide use of the library (see JLS-05) and that downstream users are likely to report discovered bugs.
 - How effective is our triage/prioritisation?
   - **Answer**: There is no development of the json library within S-CORE, and therefore no triage/prioritisation. Any identified bugs/vulnerabilities are reported to nlohmann/json. Within nlohmann/json, no formal triage process has been identified. Nevertheless, reported bugs and vulnerabilities seem to be handled in a timely manner.
 - How many components have never been updated?
   - **Answer**: None, the nlohmann/json library consists of a single header file, which the only component. This component is up to date.
 - How confident are we that we could update them?
-  - **Answer**: If a new version of the nlohmann/json library is released, we are very confident that we can update to that version.
+  - **Answer**: Within nlohmann/json, there are no external components to update. Within S-CORE, if a new version of the nlohmann/json library is released, we are very confident that we can update to that version. (See the update process in TSF/README.md)
 - How confident are we that outstanding fixes do not impact our Expectations?
-  - **Answer**: No outstanding fixes that impact the Expectation have been identified.
+  - **Answer**: No outstanding fixes that impact the Expectations have been identified.
 - How confident are we that outstanding fixes do not address Misbehaviours?
   - **Answer**: Very confident, as no Misbehaviours have been identified.
diff --git a/TSF/trustable/assertions/TA-INDICATORS_CONTEXT.md b/TSF/trustable/assertions/TA-INDICATORS_CONTEXT.md
@@ -3,6 +3,8 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 Not all deviations from Expected Behaviour can be associated with a specific
 condition. Therefore, we must have a strategy for managing deviations that
 arise from unknown system states, process vulnerabilities or configurations.
diff --git a/TSF/trustable/assertions/TA-INPUTS_CONTEXT.md b/TSF/trustable/assertions/TA-INPUTS_CONTEXT.md
@@ -3,25 +3,27 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
-Anything that can influence the output of the XYZ project is considered an input.
+Anything that can influence the output of the nlohmann/json project is considered an input.
 This includes:
 
 - Software components used to implement specified features and meet defined Expectations
 - Software tools, and their outputs, used for design, construction and verification
 - Infrastructure that supports development and release processes
 
-All inputs (components, tools, data) and their dependencies (recursively) used to build and verify XYZ releases must be identified and assessed, since they are untrusted by default.
+All inputs (components, tools, data) and their dependencies (recursively) used to build and verify nlohmann/json releases must be identified and assessed, since they are untrusted by default.
 
 Each input should be evaluated on verifiable merits, regardless of any claims it makes (including adherence to standards or guidance).
 Evaluation must include the project's defined Expectations to ensure that inputs meet requirements, and that risks are recorded and addressed appropriately.
 
-For components, we need to consider how their misbehaviour might impact achieving project XYZ's Expectations.
+For components, we need to consider how their misbehaviour might impact achieving project nlohmann/json's Expectations.
 Sources (e.g. bug databases, advisories) for known risks should be identified, their update frequency recorded, and tests defined for detecting them.
 These form the inputs to TA-FIXES.
 
-For the tools used to construct and verify XYZ, we need to consider how their misbehaviour could:
+For the tools used to construct and verify nlohmann/json, we need to consider how their misbehaviour could:
 
 - Introduce unintended changes
 - Fail to detect Misbehaviours during testing
@@ -45,28 +47,28 @@ As a result, for example, any binary inputs without reproducible build steps or
 
 **Evidence**
 
-- List of components used to build XYZ, including:
+- List of components used to build nlohmann/json, including:
   - Whether content is provided as source or binary
     - **Answer**: 
 - Record of component assessments:
   - Originating project and version
     - **Answer**: 
   - Date of assessments and identity of assessors
     - **Answer**: 
-  - Role of component in XYZ
+  - Role of component in nlohmann/json
     - **Answer**: 
   - Sources of bug and risk data
     - **Answer**: 
   - Potential misbehaviours and risks identified and assessed
     - **Answer**: 
-- List of tools used to build and verify XYZ
+- List of tools used to build and verify nlohmann/json
   - **Answer**: 
 - Record of tool assessments:
   - Originating project and tool version
     - **Answer**: 
   - Date of assessments and identity of assessors
     - **Answer**: 
-  - Role of the tool in XYZ releases
+  - Role of the tool in nlohmann/json releases
     - **Answer**: 
   - Potential misbehaviours and impacts
     - **Answer**: 
@@ -79,7 +81,7 @@ As a result, for example, any binary inputs without reproducible build steps or
 
 Confidence scoring for TA-INPUTS is based on the set of components and tools
 identified, how many of (and how often) these have been assessed for their risk
-and impact for XYZ, and the sources of risk and issue data identified.
+and impact for nlohmann/json, and the sources of risk and issue data identified.
 
 **Checklist**
 
diff --git a/TSF/trustable/assertions/TA-ITERATIONS_CONTEXT.md b/TSF/trustable/assertions/TA-ITERATIONS_CONTEXT.md
@@ -3,6 +3,8 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
 This assertion is best satisfied by checking generated documentation to confirm that:
diff --git a/TSF/trustable/assertions/TA-METHODOLOGIES_CONTEXT.md b/TSF/trustable/assertions/TA-METHODOLOGIES_CONTEXT.md
@@ -3,9 +3,11 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 **Guidance**
 
-To satisfy this assertion, all manual processes used in the verification of XYZ must be documented, including the methodologies applied, the results for specific aspects and iterations, and evidence that these processes were reviewed against documented criteria.
+To satisfy this assertion, all manual processes used in the verification of nlohmann/json must be documented, including the methodologies applied, the results for specific aspects and iterations, and evidence that these processes were reviewed against documented criteria.
 
 Most analysis (e.g., data analysis for TA-ANALYSIS) should be automated to enable continuous feedback.
 However, the quality of any remaining manual processes (whether from first parties or external third parties) must be considered and how they are documented and reviewed.
diff --git a/TSF/trustable/assertions/TA-MISBEHAVIOURS_CONTEXT.md b/TSF/trustable/assertions/TA-MISBEHAVIOURS_CONTEXT.md
@@ -3,6 +3,8 @@ level: 1.1
 normative: false
 ---
 
+(Note: The guidance, evidence, confidence scoring and checklist sections below are copied from [CodeThink's documentation of TSF](https://codethinklabs.gitlab.io/trustable/trustable/trustable/TA.html). However, the answers to each point in the evidence list and checklist are specific to this project.)
+
 The goal of TA-MISBEHAVIOURS is to force engineers to think critically about their work.
 This means understanding and mitigating as many of the situations that cause the
 software to deviate from Expected Behaviours as possible. This is not limited to
@@ -12,7 +14,7 @@ the contents of the final binary.
 
 This assertion is satisfied to the extent that we can:
 
-- Show we have identified all of the ways in which XYZ could deviate from its
+- Show we have identified all of the ways in which nlohmann/json could deviate from its
   Expected Behaviours.
 - Demonstrate that mitigations have been specified, verified and validated for
   all Misbehaviours.
@@ -57,11 +59,11 @@ Mitigations could be verified by:
 - Stress testing of assumptions of use. That is, confirming assumptions of use
   are actually consistent with the system and its Expected Behaviours by
   intentionally misinterpreting or liberally interpreting them in a test
-  environment. For example, we could consider testing XYZ on different pieces of
+  environment. For example, we could consider testing nlohmann/json on different pieces of
   hardware that satisfy its assumptions of use.
 
 Remember that a Misbehaviour is _anything_ that could lead to a deviation from
-Expected Behaviour. The specific technologies in and applications of XYZ should
+Expected Behaviour. The specific technologies in and applications of nlohmann/json should
 always be considered in addition to the guidance above.
 
 At the core, a faulty design is inherently difficult to mitigate. The first
diff --git a/TSF/trustable/assertions/TA-RELEASES_CONTEXT.md b/TSF/trustable/assertions/TA-RELEASES_CONTEXT.md
diff --git a/TSF/trustable/assertions/TA-SUPPLY_CHAIN_CONTEXT.md b/TSF/trustable/assertions/TA-SUPPLY_CHAIN_CONTEXT.md
diff --git a/TSF/trustable/assertions/TA-TESTS_CONTEXT.md b/TSF/trustable/assertions/TA-TESTS_CONTEXT.md
diff --git a/TSF/trustable/assertions/TA-UPDATES_CONTEXT.md b/TSF/trustable/assertions/TA-UPDATES_CONTEXT.md
diff --git a/TSF/trustable/assertions/TA-VALIDATION_CONTEXT.md b/TSF/trustable/assertions/TA-VALIDATION_CONTEXT.md
