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:
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 |
|---|---|---|
Problems with nlohmann_json’s implementation identified during testing are reported to the upstream nlohmann_json project. |
0.00 |
|
The build environment used for nlohmann_json in an integrating system is supplied with consistent dependencies. |
0.00 |
|
The integrator has integrator-controlled mirrors of the dependencies. |
0.00 |
|
Exceptions are properly handled or turned off. |
0.00 |
|
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 |
|
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 |
|
If the input is no valid JSON, exceptions are expected during parsing with default parameters. |
0.00 |
|
The integrator ensures that all necessary source files and built tools are mirrored, e.g. using a built server without internet access. |
0.00 |
|
TA-INDICATORS falls within the responsibility of the integrator. |
0.00 |
|
The integrator is required to evaluate the provided evidence for TA-FIXES and supplement it where necessary. |
0.00 |
|
The integrator is required to evaluate the provided evidence for TA-METHODOLOGIES and supplement it where necessary. |
0.00 |
|
The integrator is required to evaluate the provided evidence for TA-CONFIDENCE and supplement it where necessary. |
0.00 |
|
The integrator is required to evaluate the provided evidence for TA-INPUTS and supplement it where necessary. |
0.00 |
|
The JSON-library is built with tools from the provided matrix specification. (not yet provided) |
0.00 |
|
The integrator maintains mirrors for all code and tools utilized in testing. |
0.00 |
|
The integrator uses C++ versions and compilers that are tested in the CI pipeline. |
0.00 |
|
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 |
|
The integrator ensures monitoring data from deployed software is accurately captured, securely stored, and well-documented for analysis. |
0.00 |
|
The integrator ensures that monitoring data is systematically analyzed to detect trends and identify issues. |
0.00 |
Compliance for JLEX#
Compliance for JLS#
Item |
Summary |
Score |
|---|---|---|
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 |
|
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 |
|
Automated tests are reviewed by a Subject Matter Expert to verify they test the properties they claim to. |
0.00 |
|
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 |
|
The OSS nlohmann_json is widely used, actively maintained and uses github issues to track bugs and misbehaviours. |
0.00 |
|
Changes to the code (main branch) are applied only after code review and passing of all pipelines. |
0.00 |
|
Main branch is protected, i.e. no direct commits are possible. |
0.00 |
|
Each statement is scored based on SME reviews or automatic validation functions. (TODO) |
0.00 |
|
Scores are reasonably, systematically and repeatably accumulated. (TODO) |
0.00 |
|
Every release includes source code, build instructions, tests and attestations. (TODO: Test result summary) |
0.00 |
|
A score based on outstanding, fixed and mitigated faults is calculated based on github issues in nlohmann/json. (TODO) |
0.00 |
|
The S-Core change process management is followed. (https://eclipse-score.github.io/process_description/main/process_areas/change_management/index.html) |
0.00 |
|
The S-Core methodologies are followed. (https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html). |
0.00 |
|
The builds are repeatable (i.e. different builds lead to the same SHA value). (TODO) |
0.00 |
|
A list of tests, which is extracted from the test execution, is provided, along with a list of test environments. (TODO) |
0.00 |
|
A github workflow calculates the fraction of expectations covered by tests (TODO). |
0.00 |
|
Results from tests are accurately captured. (TODO) |
0.00 |
|
All components, dependencies and tools are listed in a manifest. |
0.00 |
|
A github workflow saves the history of scores in the trustable graph to derive trends. (TODO) |
0.00 |
|
A score is calculated based on the number of mirrored and unmirrored things. (TODO) |
0.00 |
|
The github workflow executes the unit tests daily and saves the results as time-series data. (TODO) |
0.00 |
|
The eclipse s-core organization mirrors the nlohmann_json library in a fork. |
0.00 |
|
The JSON library recognizes malformed JSON and returns an exception. |
0.00 |
|
Malicious code changes are mitigated by code reviews, adhering to Eclipse S-core contribution procedures and vigilance from the open-source community. |
0.00 |
|
Pipeline execution results are analyzed in the fork and the original nlohmann_json repository. |
0.00 |
Compliance for PJD#
Item |
Summary |
Score |
|---|---|---|
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 |
|
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 |
|
The service parses all texts that conform to the JSON grammar. |
0.00 |
|
The service correctly parses 64-bit integers (exceeding the range defined in RFC8259). |
0.00 |
Compliance for TA#
Item |
Summary |
Score |
|---|---|---|
Collected data from tests and monitoring of deployed software is analysed according to specified objectives. |
0.00 |
|
Expected or required behaviours for JSON-Library are identified, specified, verified and validated based on analysis. |
0.00 |
|
Confidence in JSON-Library is measured based on results of analysis. |
0.00 |
|
Constraints on adaptation and deployment of JSON-Library are specified. |
0.00 |
|
Data is collected from tests, and from monitoring of deployed software, according to specified objectives. |
0.00 |
|
Known bugs or misbehaviours are analysed and triaged, and critical fixes or mitigations are implemented or applied. |
0.00 |
|
Advanced warning indicators for misbehaviours are identified, and monitoring mechanisms are specified, verified and validated based on analysis. |
0.00 |
|
All inputs to JSON-Library are assessed, to identify potential risks and issues. |
0.00 |
|
All constructed iterations of JSON-Library include source code, build instructions, tests, results and attestations. |
0.00 |
|
Manual methodologies applied for JSON-Library by contributors, and their results, are managed according to specified objectives. |
0.00 |
|
Prohibited misbehaviours for JSON-Library are identified, and mitigations are specified, verified and validated based on analysis. |
0.00 |
|
Construction of JSON-Library releases is fully repeatable and the results are fully reproducible, with any exceptions documented and justified. |
0.00 |
|
All sources for JSON-Library and tools are mirrored in our controlled environment. |
0.00 |
|
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 |
|
JSON-Library components, configurations and tools are updated under specified change and configuration management controls. |
0.00 |
|
All specified tests are executed repeatedly, under defined conditions in controlled environments, according to specified objectives. |
0.00 |
Compliance for TRUSTABLE#
Item |
Summary |
Score |
|---|---|---|
This release of JSON-Library is Trustable. |
0.00 |
Compliance for TT#
Item |
Summary |
Score |
|---|---|---|
JSON-Library is actively maintained, with regular updates to dependencies, and changes are verified to prevent regressions. |
0.00 |
|
Confidence in JSON-Library is achieved by measuring and analysing behaviour and evidence over time. |
0.00 |
|
Tools are provided to build JSON-Library from trusted sources (also provided) with full reproducibility. |
0.00 |
|
Documentation is provided, specifying what JSON-Library is expected to do, and what it must not do, and how this is verified. |
0.00 |
|
All inputs (and attestations for claims) for JSON-Library are provided with known provenance. |
0.00 |
|
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 |
|---|---|---|
The service checks for the four primitive types (strings, numbers, booleans, null). |
0.00 |
|
The service checks for the two structured types (objects, arrays). |
0.00 |
|
The service checks the defined JSON grammar (six structural characters ([]{},:), strings, numbers, three literal names (true,false,null)). |
0.00 |
|
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 |
|
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 |
|
The service checks that strings follow the standard described in RFC 8259 in section 7. |
0.00 |
|
The service checks that an array structure is represented as square brackets surrounding zero or more values (or elements). |
0.00 |
|
The service checks that elements/ names/ values are separated by a single comma. |
0.00 |
|
The service checks that numbers are represented in base 10 using decimal digits with an optional prefixed minus sign according to RFC8259. |
0.00 |
|
The service checks that strings are represented by the similar convention used in C programming languages. |
0.00 |
|
The service checks that JSON is only serialized and deserialized using UTF-8. |
0.00 |
|
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