Provide a CSV file for the security evidence of runtime components
See original GitHub issueMake the information available together with the one provided by the Canton and Ledgers team as a CSV file bundled with every release, to which the documentation points
Currently, the TEST_EVIDENCE
annotations are processed to generate the security-evidence.md
file.
Either adapt the generator to (additionally) output a CSV file or move to scalatest style annotations (lib-scala/test-evidence).
Part of #14254
Issue Analytics
- State:
- Created a year ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Known Exploited Vulnerabilities Catalog
A successful exploit could allow the attacker to view arbitrary files within the web services file system on the targeted device. The web...
Read more >Create a Standard Decision Matrix by Using a CSV File
Use a CSV file to create decision matrices, especially if you're dealing with sizable data, and save the time and effort of manually...
Read more >Comma-Separated Value (CSV) identity feed
The Comma-Separated Value (CSV) identity feed provides capability for reading comma-separated value (CSV) file to add users to IBM® Security Identity Manager.
Read more >Security Event Log - an overview
The script is capable of parsing event records into either CSV format, suitable for opening Excel, or into a format suitable for timeline...
Read more >What is CVE and CVSS | Vulnerability Scoring Explained
CVE is a glossary that classifies vulnerabilities. The glossary analyzes vulnerabilities and then uses the Common Vulnerability Scoring System (CVSS) to ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The idea is that of moving away from the framework built around the
TEST_EVIDENCE
tag to make it easier to integrate the security evidence artifacts with the ones provided as CSV by other teams. As such, the tag cannot be put freely in the source code but needs to annotate a specific ScalaTest test case, which is what creates the problem. As such, I would recommend to do one of the following:As mentioned, any action should more or less derive from the threat modeling document for the component under test. Please note that components like the Daml engine and interpreter are under the responsibility of the Daml-LF team and @remyhaemmerle-da will work together with @soren-da to move forward with those.
@cbley-da As part of the scope that we aim to address before the end of the year are only the Ledger Clients components, which means the OAuth 2.0 Auth Middleware, the Java bindings, the HTTP JSON API service, the TypeScript bindings, the React.js bindings, and the Trigger Service (but not the Trigger Runner).
@stefanobaghino-da I am not very queen on defactorizing, my test in order to improve generation of test evidence documentation. Repetitions make easy introduction of bugs when we need to change something and make review a very tiring task.
In this case, we can simply factorize all the test evidences in a single one, with something like :