|
![TSS_PNG](/uploads/3ec5ebdb12fe7f923b471a02d23f5ed5/TSS_PNG.png)
|
|
![TSS_PNG](/uploads/3ec5ebdb12fe7f923b471a02d23f5ed5/TSS_PNG.png)
|
|
|
|
|
|
The process starts by capturing requirements (for example in a [mustard](https://gitlab.com/trustable/overview/wikis/report#mustard) yaml file).
|
|
The process starts by capturing requirements (for example in a [mustard](https://gitlab.com/trustable/overview/wikis/report#mustard) yaml file). These requirements are written in such a way that the individual rules of a standard are encapsulated where possible, and they must be both machine testable and human readable. They are contained in the project repo.
|
|
|
|
|
|
These requirements are written in such a way that the individual rules of a standard are encapsulated where possible, and in GIVEN/WHEN/THEN [BDD-style](https://gitlab.com/trustable/overview/wikis/Trustable_BDD) scenarios. As such, requirements (and thus, standard compliances) are now in a format which can be tested against the code, using an existing BDD tool such as Yarn or Behave. This metadata is contained in the project repo.
|
|
A patch review system is put in place, which ensures that each revision is traceable to the developer (this will require careful implementation). If the code within the patch satisfies a previously unaddressed requirement or introduces a new feature, this must be expressly stated in the commit message. The enforcement of this aspect can be partially automated (patches that do not have an explanation message, or the correct credentials, can be rejected, for example), however the commit messages are primarily for ease of human auditing, and will be retained as metadata for consumption downstream in the process when documentation is generated.
|
|
|
|
|
|
A patch review system is put in place, which ensures that each revision is traceable to the developer. If the code within the patch satisfies a previously un-addressed requirement or introduces a new feature, this must be expressly stated in the commit message. The patch tracker is integrated with a CI system, which ensures that a submitted patch does not break any features, and reports what downstream changes it is responsible for. This means that a scenario (describing a particular requirement of the system) can be shown to function as expected, as well as being directly linked to specific SLOC and the developer who merged it. Often, a standard will dictate its own rules regarding patch review, which can be integrated at this point.
|
|
The patch tracker is integrated with a CI system, which ensures that a submitted patch does not break any features. This means that code which implements a particular requirement of the system can be shown to function as expected, as well as being directly linked to specific SLOC and the developer who merged it. Often, a standard will dictate its own rules regarding patch review, which can be integrated at this point.
|
|
|
|
|
|
The CI runs the tests set out in the initial G/W/T-format requirements, and test results are produced as a standalone artifact. An automerger is configured with both human and machine reviewing, which creates a branch consumed by a continuous deployment system.
|
|
The CI runs tests on the code, and test results are produced as a standalone artifact. An automerger is configured with both human and machine reviewing, which creates a branch consumed by a continuous deployment system.
|
|
|
|
|
|
The metadata for each individual requirement and standard control can be consistently updated by the CD system with information from the test result artifacts. This way, the scenario for each requirement that has been satisfied carries with it results from a passing test, information about who submitted the patch(es), and the commit message detailing how the patch satisfies the requirement. This metadata can be consumed by an automatic compliance document generator, such as Compliance Masonry, to produce a consistently up-to-date SSP as the project develops. |
|
The CD system runs a script which consumes the requirements yaml, as well as the test result artifacts and information from the patch tracker to generate an output with a compliance narrative for each individual requirement/standard control (including the patch commit messages), their accompanying test results, and information about who submitted the patch(es). This is updated every time there is a revision to the code, requirements or standard. This output can be consumed by an automatic compliance document generator (such as [Compliance Masonry](https://gitlab.com/trustable/overview/wikis/opencontrol-compliance-masonry-example)) to produce consistently up-to-date compliance documentation as the project develops. |
|
\ No newline at end of file |
|
\ No newline at end of file |