# Trustable Compliance Report ## Item status guide Each item in a Trustable Graph is scored with a number between 0 and 1. The score represents aggregated organizational confidence in a given Statement, with larger numbers corresponding to higher confidence. Scores in the report are indicated by both a numerical score and the colormap below:
1.00   0.00
The status of an item and its links also affect the score. Unreviewed items are indicated by a strikethrough. The score of unreviewed items is always set to zero. Suspect links are indicated by italics. The contribution to the score of a parent item by a suspiciously linked child is always zero, regardless of the child's own score. ## Compliance for AOU | Item | Summary | Score | |--------|---------|-------| | [AOU-01](AOU.md#aou-01) | Problems with nlohmann_json's implementation identified during testing are reported to the upstream nlohmann_json project. | 0.00 | | [AOU-02](AOU.md#aou-02) | The build environment used for nlohmann_json in an integrating system is supplied with consistent dependencies. | 0.00 | | [AOU-03](AOU.md#aou-03) | The integrator has integrator-controlled mirrors of the dependencies. | 0.00 | | [AOU-04](AOU.md#aou-04) | Exceptions are properly handled or turned off. | 0.00 | | [AOU-05](AOU.md#aou-05) | Input is encoded as UTF-8 (as required by RFC8259) and in case other string formats are used, it is expected that the parse or dump function may throw an exception. | 0.00 | | [AOU-06](AOU.md#aou-06) | Brace initialization (e.g. json j{true};) is not used with the types basic_json, json, or ordered_json unless you want to create an object or array. | 0.00 | | [AOU-07](AOU.md#aou-07) | If the input is no valid JSON, exceptions are expected during parsing with default parameters. | 0.00 | | [AOU-08](AOU.md#aou-08) | The integrator ensures that all necessary source files and built tools are mirrored, e.g. using a built server without internet access. | 0.00 | | [AOU-09](AOU.md#aou-09) | TA-INDICATORS falls within the responsibility of the integrator. | 0.00 | | [AOU-10](AOU.md#aou-10) | The integrator is required to evaluate the provided evidence for TA-FIXES and supplement it where necessary. | 0.00 | | [AOU-11](AOU.md#aou-11) | The integrator is required to evaluate the provided evidence for TA-METHODOLOGIES and supplement it where necessary. | 0.00 | | [AOU-12](AOU.md#aou-12) | The integrator is required to evaluate the provided evidence for TA-CONFIDENCE and supplement it where necessary. | 0.00 | | [AOU-13](AOU.md#aou-13) | The integrator is required to evaluate the provided evidence for TA-INPUTS and supplement it where necessary. | 0.00 | | [AOU-14](AOU.md#aou-14) | The JSON-library is built with tools from the provided matrix specification. (not yet provided) | 0.00 | | [AOU-15](AOU.md#aou-15) | The integrator maintains mirrors for all code and tools utilized in testing. | 0.00 | | [AOU-16](AOU.md#aou-16) | The integrator uses C++ versions and compilers that are tested in the CI pipeline. | 0.00 | | [AOU-17](AOU.md#aou-17) | The integrator is responsible for identifying additional misbehaviours for the JSON library, defining appropriate mitigations, and ensuring that these mitigations are thoroughly validated. | 0.00 | | [AOU-18](AOU.md#aou-18) | The integrator ensures monitoring data from deployed software is accurately captured, securely stored, and well-documented for analysis. | 0.00 | | [AOU-19](AOU.md#aou-19) | The integrator ensures that monitoring data is systematically analyzed to detect trends and identify issues. | 0.00 | ## Compliance for JLEX | Item | Summary | Score | |--------|---------|-------| | [JLEX-01](JLEX.md#jlex-01) | The JSON-Library provides a service to check the well-formedness of JSON data. | 0.00 | | [JLEX-02](JLEX.md#jlex-02) | The JSON-Library provides a service to parse JSON data according to RFC8259. | 0.00 | ## Compliance for JLS | Item | Summary | Score | |--------|---------|-------| | [JLS-01](JLS.md#jls-01) | The JSON-library project CI executes on each pull request (opened, reopened, synchronized) the integration test suite, and failures in these runs are investigated by contributors. | 0.00 | | [JLS-02](JLS.md#jls-02) | Fuzz testing is used to uncover edge cases and failure modes throughout development. (https://github.com/nlohmann/json/blob/develop/tests/fuzzing.md) | 0.00 | | [JLS-03](JLS.md#jls-03) | Automated tests are reviewed by a Subject Matter Expert to verify they test the properties they claim to. | 0.00 | | [JLS-04](JLS.md#jls-04) | The project runs dependabot on all code entering the main branch, blocking merges until all warnings are resolved. (https://github.com/score-json/json/blob/main/nlohmann_json/.github/dependabot.yml) | 0.00 | | [JLS-05](JLS.md#jls-05) | The OSS nlohmann_json is widely used, actively maintained and uses github issues to track bugs and misbehaviours. | 0.00 | | [JLS-06](JLS.md#jls-06) | Changes to the code (main branch) are applied only after code review and passing of all pipelines. | 0.00 | | [JLS-07](JLS.md#jls-07) | Main branch is protected, i.e. no direct commits are possible. | 0.00 | | [JLS-08](JLS.md#jls-08) | Each statement is scored based on SME reviews or automatic validation functions. (TODO) | 0.00 | | [JLS-09](JLS.md#jls-09) | Scores are reasonably, systematically and repeatably accumulated. (TODO) | 0.00 | | [JLS-10](JLS.md#jls-10) | Every release includes source code, build instructions, tests and attestations. (TODO: Test result summary) | 0.00 | | [JLS-11](JLS.md#jls-11) | A score based on outstanding, fixed and mitigated faults is calculated based on github issues in nlohmann/json. (TODO) | 0.00 | | [JLS-12](JLS.md#jls-12) | The S-Core change process management is followed. (https://eclipse-score.github.io/process_description/main/process_areas/change_management/index.html) | 0.00 | | [JLS-13](JLS.md#jls-13) | The S-Core methodologies are followed. (https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html). | 0.00 | | [JLS-14](JLS.md#jls-14) | The builds are repeatable (i.e. different builds lead to the same SHA value). (TODO) | 0.00 | | [JLS-16](JLS.md#jls-16) | A list of tests, which is extracted from the test execution, is provided, along with a list of test environments. (TODO) | 0.00 | | [JLS-17](JLS.md#jls-17) | A github workflow calculates the fraction of expectations covered by tests (TODO). | 0.00 | | [JLS-18](JLS.md#jls-18) | Results from tests are accurately captured. (TODO) | 0.00 | | [JLS-19](JLS.md#jls-19) | All components, dependencies and tools are listed in a manifest. | 0.00 | | [JLS-20](JLS.md#jls-20) | A github workflow saves the history of scores in the trustable graph to derive trends. (TODO) | 0.00 | | [JLS-21](JLS.md#jls-21) | A score is calculated based on the number of mirrored and unmirrored things. (TODO) | 0.00 | | [JLS-22](JLS.md#jls-22) | The github workflow executes the unit tests daily and saves the results as time-series data. (TODO) | 0.00 | | [JLS-23](JLS.md#jls-23) | The eclipse s-core organization mirrors the nlohmann_json library in a fork. | 0.00 | | [JLS-24](JLS.md#jls-24) | The JSON library recognizes malformed JSON and returns an exception. | 0.00 | | [JLS-25](JLS.md#jls-25) | Malicious code changes are mitigated by code reviews, adhering to Eclipse S-core contribution procedures and vigilance from the open-source community. | 0.00 | | [JLS-26](JLS.md#jls-26) | Pipeline execution results are analyzed in the fork and the original nlohmann_json repository. | 0.00 | ## Compliance for PJD | Item | Summary | Score | |--------|---------|-------| | [PJD-01](PJD.md#pjd-01) | The service provides implementations that parses JSON texts, which ignores the presence of a byte order mark rather than treating it as an error. | 0.00 | | [PJD-02](PJD.md#pjd-02) | The service transforms a JSON text into a C++ representation using C++ containers (for arrays and objects) and primitive datatypes (for strings, numbers, boolean, null). | 0.00 | | [PJD-03](PJD.md#pjd-03) | The service parses all texts that conform to the JSON grammar. | 0.00 | | [PJD-04](PJD.md#pjd-04) | The service correctly parses 64-bit integers (exceeding the range defined in RFC8259). | 0.00 | ## Compliance for TA | Item | Summary | Score | |--------|---------|-------| | [TA-ANALYSIS](TA.md#ta-analysis) | Collected data from tests and monitoring of deployed software is analysed according to specified objectives. | 0.00 | | [TA-BEHAVIOURS](TA.md#ta-behaviours) | Expected or required behaviours for JSON-Library are identified, specified, verified and validated based on analysis. | 0.00 | | [TA-CONFIDENCE](TA.md#ta-confidence) | Confidence in JSON-Library is measured based on results of analysis. | 0.00 | | [TA-CONSTRAINTS](TA.md#ta-constraints) | Constraints on adaptation and deployment of JSON-Library are specified. | 0.00 | | [TA-DATA](TA.md#ta-data) | Data is collected from tests, and from monitoring of deployed software, according to specified objectives. | 0.00 | | [TA-FIXES](TA.md#ta-fixes) | Known bugs or misbehaviours are analysed and triaged, and critical fixes or mitigations are implemented or applied. | 0.00 | | [TA-INDICATORS](TA.md#ta-indicators) | Advanced warning indicators for misbehaviours are identified, and monitoring mechanisms are specified, verified and validated based on analysis. | 0.00 | | [TA-INPUTS](TA.md#ta-inputs) | All inputs to JSON-Library are assessed, to identify potential risks and issues. | 0.00 | | [TA-ITERATIONS](TA.md#ta-iterations) | All constructed iterations of JSON-Library include source code, build instructions, tests, results and attestations. | 0.00 | | [TA-METHODOLOGIES](TA.md#ta-methodologies) | Manual methodologies applied for JSON-Library by contributors, and their results, are managed according to specified objectives. | 0.00 | | [TA-MISBEHAVIOURS](TA.md#ta-misbehaviours) | Prohibited misbehaviours for JSON-Library are identified, and mitigations are specified, verified and validated based on analysis. | 0.00 | | [TA-RELEASES](TA.md#ta-releases) | Construction of JSON-Library releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. | 0.00 | | [TA-SUPPLY_CHAIN](TA.md#ta-supply_chain) | All sources for JSON-Library and tools are mirrored in our controlled environment. | 0.00 | | [TA-TESTS](TA.md#ta-tests) | All tests for JSON-Library, and its build and test environments, are constructed from controlled/mirrored sources and are reproducible, with any exceptions documented. | 0.00 | | [TA-UPDATES](TA.md#ta-updates) | JSON-Library components, configurations and tools are updated under specified change and configuration management controls. | 0.00 | | [TA-VALIDATION](TA.md#ta-validation) | All specified tests are executed repeatedly, under defined conditions in controlled environments, according to specified objectives. | 0.00 | ## Compliance for TRUSTABLE | Item | Summary | Score | |--------|---------|-------| | [TRUSTABLE-SOFTWARE](TRUSTABLE.md#trustable-software) | This release of JSON-Library is Trustable. | 0.00 | ## Compliance for TT | Item | Summary | Score | |--------|---------|-------| | [TT-CHANGES](TT.md#tt-changes) | JSON-Library is actively maintained, with regular updates to dependencies, and changes are verified to prevent regressions. | 0.00 | | [TT-CONFIDENCE](TT.md#tt-confidence) | Confidence in JSON-Library is achieved by measuring and analysing behaviour and evidence over time. | 0.00 | | [TT-CONSTRUCTION](TT.md#tt-construction) | Tools are provided to build JSON-Library from trusted sources (also provided) with full reproducibility. | 0.00 | | [TT-EXPECTATIONS](TT.md#tt-expectations) | Documentation is provided, specifying what JSON-Library is expected to do, and what it must not do, and how this is verified. | 0.00 | | [TT-PROVENANCE](TT.md#tt-provenance) | All inputs (and attestations for claims) for JSON-Library are provided with known provenance. | 0.00 | | [TT-RESULTS](TT.md#tt-results) | Evidence is provided to demonstrate that JSON-Library does what it is supposed to do, and does not do what it must not do. | 0.00 | ## Compliance for WFJ | Item | Summary | Score | |--------|---------|-------| | [WFJ-01](WFJ.md#wfj-01) | The service checks for the four primitive types (strings, numbers, booleans, null). | 0.00 | | [WFJ-02](WFJ.md#wfj-02) | The service checks for the two structured types (objects, arrays). | 0.00 | | [WFJ-03](WFJ.md#wfj-03) | The service checks the defined JSON grammar (six structural characters ([]{},:), strings, numbers, three literal names (true,false,null)). | 0.00 | | [WFJ-04](WFJ.md#wfj-04) | The service checks that a JSON value must be an object, array, number, or string, or one of the lowercase literal names: false, null, or true. | 0.00 | | [WFJ-05](WFJ.md#wfj-05) | The service checks that an object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). | 0.00 | | [WFJ-06](WFJ.md#wfj-06) | The service checks that strings follow the standard described in RFC 8259 in section 7. | 0.00 | | [WFJ-07](WFJ.md#wfj-07) | The service checks that an array structure is represented as square brackets surrounding zero or more values (or elements). | 0.00 | | [WFJ-08](WFJ.md#wfj-08) | The service checks that elements/ names/ values are separated by a single comma. | 0.00 | | [WFJ-09](WFJ.md#wfj-09) | The service checks that numbers are represented in base 10 using decimal digits with an optional prefixed minus sign according to RFC8259. | 0.00 | | [WFJ-10](WFJ.md#wfj-10) | The service checks that strings are represented by the similar convention used in C programming languages. | 0.00 | | [WFJ-11](WFJ.md#wfj-11) | The service checks that JSON is only serialized and deserialized using UTF-8. | 0.00 | | [WFJ-12](WFJ.md#wfj-12) | The service provides implementations that parse JSON texts, which ignores the presence of a byte order mark rather than treating it as an error. | 0.00 | --- _Generated for: Software_ * _Repository root: /home/runner/work/json/json_ * _Commit SHA: 3200103edb251f175305b8a941c53d7a2258be02_ * _Commit date/time: Fri Aug 8 15:44:06 2025_ * _Commit tag: 3200103_