1 TC: Verify data modelling artifacts TST-001

Preconditions and setup actions

  • Access to the SATRAP-DL system concept documents
  • Access to the SATRAP-DL database schema
  • Access to the SATRAP-DL system deployment artifacts
  • Access to the SATRAP-DL source code

Test steps

  1. Review the SATRAP-DL system concept documents, database schema, deployment artifacts and source code to verify the linked requirements related to data modelling, database paradigm, integration of semantic search capable technology and flexibility of DBMS.
  2. Check for alignment by comparing the system concept documents with the database schema and deployment artifacts to ensure that there is consistency between them, e.g., that the database schema accurately reflects the data model specified in the documents.

Expected outcome

As the verification method of this TC is review of design, the expected outcomes are already embedded in the test steps.

Parent links: SRS-001 Data modelling language, SRS-002 Database paradigm, SRS-003 Semantic search, SRS-004 Extensibility of the data model, SRS-005 NoSQL data model

Child links: TRA-001 TCER: modelling

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Review of design (R)
release alpha
complexity 1
test_data see referenced files
version 0.1

2 TC: Verify software engineering TST-002

Verify that the design and implementation of SATRAP-DL adheres to software best practices.

Preconditions and setup actions

  • Access to SATRAP-DL source code

Test steps

  1. Verify the consistent use of naming conventions.
  2. Verify adherence to SOLID, the 5 principles of object-oriented design SOLID principles.

Expected outcome

  1. Naming convention either explicitly defined or referenced (e.g., inherited from PEP-8) and the implementation largely complies with the choice.
  2. Main architectural modules adhere to the SOLID design principles.

Parent links: SRS-024 Design and implementation principles

Child links: TRA-002 TCER: SW engineering

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Review of design (R)
release alpha
complexity 3
test_data see referenced files
version 0.1

3 TC: Verify STIX and reasoning engine TST-003

Verify usage of DBMS equipped with automated reasoning and the use of the STIX 2.1 standard for CTI representation.

Preconditions and setup actions

  • Access to SATRAP-DL database
  • Access to SATRAP-DL source code

Test steps

  1. Verify that the DBMS technology used in SATRAP-DL integrates or has compatibility with an automated reasoning engine, with the preferred solution being TypeDB.
  2. Verify that SATRAP-DL uses STIX 2.1 as the default standard format for CTI representation.

Expected outcome

Embedded in test steps.

Parent links: SRS-014 Native reasoning engine, SRS-023 CTI representation in STIX 2.1

Child links: TRA-003 TCER: STIX and reasoning

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Review of design (R), Inspection (I)
release alpha
complexity 1
test_data see referenced files
version 0.1

4 TC: Verify data model TST-004

Analyze data model adherence to that of STIX 2.1.

Preconditions and setup actions

  • Access to the SATRAP-DL database schema
  • Access to the SATRAP-DL source code

Test steps

  1. Verify that the data model of SATRAP-DL is aligned with the data model of STIX 2.1: check for correct mapping and interpretation for all non-custom properties.

Expected outcome

Embedded in test steps.

Parent links: SRS-013 STIX 2.1 data model

Child links: TRA-004 TCER: data model

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Analysis (A)
release alpha
complexity 5
test_data see referenced files
version 0.1

5 TC: Verify centralized management TST-005

Verify centralized management of system parameters customization (e.g., logging severity, db connections, file paths) via a dedicated configuration file, log storage, exception types and error messages.

Preconditions and setup actions

  • Access to the SATRAP-DL source code

Test steps

  1. Verify that system parameters for logging severity can be customized in a centralized manner: e.g., logging severity: debug, info, warn, error
  2. Verify that system parameters for db connections can be customized in a centralized manner.
  3. Verify that system parameters for file paths can be managed from a dedicated, centralized configuration file.
  4. Verify that there is a designated centralized location for storing logs.
  5. Verify that exceptions are specified in a centralized manner, e.g., by maintaining all the error codes in a configuration file.

Expected outcome

Embedded in test steps.

Parent links: SRS-020 System configuration file, SRS-021 Centralized logging, SRS-022 Centralized exception handling

Child links: TRA-005 TCER: centralized management

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Inspection (I)
release alpha
complexity 2
test_data see referenced files
version 0.1

6 TC: Verify code clarity TST-006

Verify source code documentation and readability quality, as well as release on GitHub.

Preconditions and setup actions

  • Access to SATRAP-DL source code
  • Access to GitHub

Test steps

  1. Verify that the source code of SATRAP-DL, at the level of class and function definitions, is implemented either in a self-explanatory manner or that it is well documented within the source code, e.g., using doc strings.

Expected outcome

Embedded in test steps.

Parent links: SRS-025 Code readability

Child links: TRA-006 TCER: code clarity

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Inspection (I)
release alpha
complexity 3
test_data see referenced files
version 0.1

7 TC: Verify secure programming TST-007

Ensure various input sanitization and validation security measures are in place.

Preconditions and setup actions

  • Access to the SATRAP-DL data models and database schema
  • Access to the SATRAP-DL source code

Test steps

  1. Verify that SATRAP-DL components receiving input validate the input and reject it in case the validation fails; the validation may include integrity checks, syntactic checks, semantic checks, parameter out-of-range checks, etc.
  2. Verify that SATRAP-DL perform sanitization of input and output (data passed across a trust boundary); sanitization may include removing, replacing, encoding, or escaping unwanted characters.
  3. Verify that network connections and other resources accessed are properly terminated when they are no longer required.
  4. Verify that all software dependencies including 3rd-party libraries are listed and maintained in a configuration file.
  5. Verify that log strings are sanitized and validated before being logging to prevent log injection attacks.
  6. Verify that SATRAP-DL does not log sensitive information such as passwords or entity identifiers.
  7. Verify that the data model enforces semantic integrity ensuring that relationships and constraints adhere to the intended meaning; this can be based on measures such as data validation with respect to schemas and relationship constraints, technical possibility of automated checks for data redundancy and inference powered by a reasoning engine.

Expected outcome

Embedded in test steps.

Parent links: SRS-007 Semantic data integrity, SRS-028 Input validation, SRS-029 Input sanitization, SRS-030 Resource management, SRS-032 Dependencies management, SRS-036 Log validation, SRS-037 Sensitive information

Child links: TRA-007 TCER: secure programming

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Inspection (I), Review of design (R)
release alpha
complexity 3
test_data see referenced files
version 0.1

8 Test setup + MITRE ATT&CK ingestion TST-008

Test the SATRAP initialization and setup/deployment scripts and its mechanism for retrieving datasets from MITRE ATT&CK in STIX 2.1, and making them available for other system components to adequately process and insert the information into the CTI SKB.

Preconditions and setup actions

  • Access to the SATRAP-DL deployment artifacts
  • Access to the internet or a pre-downloaded copy of MITRE ATT&CK data sets in STIX 2.1, e.g., the enterprise TTPs
  • TypeDB Docker container pulled and running using the init-satrap.sh script
  • SATRAP Docker network created using the init-satrap.sh script
  • SATRAP volume for persistent TypeDB storage created using the init-satrap.sh script
  • Docker Engine (or daemon) running with the right privileges for the testing user
  • TypeDB Studio version 2.28.6 installed: Link to GitHub release (alternatively you can interact with the TypeDB backend directly via its CLI)
  • A plain/empty project created in TypeDB Studio
  • SATRAP Docker container created using the build-satrap.sh script

Test steps

  1. Run the SATRAP setup CLI command to create the SATRAP TypeDB data schema for STIX 2.1 and load it into the CTI SKB.
$ ./satrap.sh setup

Starting SATRAP...
Database 'satrap-skb-alpha' will be created at 'typedb:1729'
Do you want to continue? (y/n): y
Database 'satrap-skb-alpha' successfully created from:
Schema: /home/alab/cti-analysis-platform/satrap/assets/schema/cti-skb-types.tql
Rules: /home/alab/cti-analysis-platform/satrap/assets/schema/cti-skb-rules.tql
  1. Run the SATRAP etl CLI command to run the ETL (Extract, Transform, Load) pipeline for the ATT&CK enterprise TTP data set selected by default, confirm by typing yes and pressing enter.
$ ./satrap.sh etl

Starting SATRAP...

The ETL process will be executed with the following parameters (modify at 'satrap_params.yml'):

Extraction datasource: https://raw.githubusercontent.com/mitre-attack/attack-stix-data/master/enterprise-attack/enterprise-attack.json
Load into: database 'satrap-skb-alpha' at typedb:1729

Do you want to continue? (yes/no): yes

Logging to file: /home/alab/cti-analysis-platform/satrap/assets/logs/2025-03-29/info.log

Expected outcome

  1. Start TypeDB Studio, select your database as shown below (satrap-skb-alpha):

TypeDB Studio database selection

  • Open your previously created TypeDB project (or create a fresh one)
  • Press the Export Schema Types button from the TypeDB Browser, as shown below

TypeDB Studio Data Schema Types export

  • Save the exported content in a .tql file, e.g., test-schema.tql and compare the content of this file with the evidence provided in our test data (a simple diff will do); the path to the reference schema is indicated here.
  1. Once the ETL execution is finished, the printout in the terminal should read a total of 215498 entries. Note that the correctness of the actual mappings and correspondence soundness between the transformed content loaded into TypeDB is tested via our comprehensive unit test suites found under tests folder at the project root, which can be run using our run_tests.sh script.

docs/specs/TST/assets/satrap-schema-types.tql

Parent links: SRS-006 Integration of common CTI, SRS-043 TypeDB Studio

Child links: TRA-008 TCER: MITRE ATT&CK ingestion

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Test (T)
release alpha
complexity 2
test_data see referenced files
version 0.1

9 Verify ETL architecture TST-009

Preconditions and setup actions

  • Access to the SATRAP-DL system concept documents

Test steps

  1. Verify that the ETL module of SATRAP-DL provides a component in charge of orchestrating the ingestion of datasets in STIX 2.1 and the insertion of the content into the CTI SKB.
  2. Verify that the ETL module of SATRAP-DL provides a component in charge of transforming data in STIX 2.1 format into the representation language of the the CTI SKB schema.
  3. Verify that SATRAP-DL provides a component in charge of managing database operations and connections.

Expected outcome

Embedded in test steps.

Parent links: SRS-008 ETL orchestrator, SRS-009 ETL Transformer, SRS-010 Database manager

Child links: TRA-009 TCER: ETL architecture

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Review of design (R)
release alpha
complexity 2
test_data see referenced files
version 0.1

10 Verify CTI SKB inference rules TST-010

Preconditions and setup actions

  • Access to the SATRAP-DL source code

Test steps

  1. Verify that SATRAP-DL implements inference rules that allow for the automated derivation of knowledge over existing relations in the CTI SKB by inspecting the CTI SKB inference rule definition file and CTI SKB type definitions files stored in the satrap/assets/schema folder.

Expected outcome

Embedded in test steps.

satrap/assets/schema/cti-skb-rules.tql satrap/assets/schema/cti-skb-types.tql

Parent links: SRS-012 Inference rules

Child links: TRA-010 TCER: CTI SKB inference

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Analysis (A)
release alpha
complexity 5
test_data see referenced files
version 0.1

11 Test Jupyter notebook frontend TST-011

Test that the provided Jupyter notebook frontend executes as expected.

Preconditions and setup actions

  • Access to source code of SATRAP-DL
  • Access to SATRAP-DL deployment artifacts
  • Access to the internet or a pre-downloaded copy of MITRE ATT&CK data sets in STIX 2.1, e.g., the enterprise TTPs
  • TypeDB Docker container pulled and running using the init-satrap.sh script
  • SATRAP Docker network created using the init-satrap.sh script
  • SATRAP volume for persistent TypeDB storage created using the init-satrap.sh script
  • Docker Engine (or daemon) running with the right privileges for the testing user
  • TypeDB Studio version 2.28.6 installed (alternatively you can interact with the TypeDB backend directly via its CLI)
  • A plain/empty project created in TypeDB Studio
  • SATRAP Docker container created using the build-satrap.sh script
  • Microsoft VS Code Studio installed (v1.98.2)
  • Microsoft VS Code Studio Dev Containers installed, i.e., the VS Code extension (v0.401.0)

Test dependencies

  • TST-008 executed successfully

Test steps

  1. Open the source code of SATRAP-DL (here we assume the use of VS Code) and open the project in the dev container (see the README).
  2. Navigate to the VS Code Studio terminal and create a new Terminal (if a prompt not available) to access the SATRAP container file system and run poetry shell, followed by poetry install.
  3. Navigate to the folder satrap/frontend/quick_start.ipynb and using the Select kernel button, choose the Python environment that was just activated and prepared using the commands in the previous step.
  4. Run each cell from top to bottom in order.

Expected outcome

  1. The obtained outcome must match the test data evidence available in satrap/docs/specs/TST/assets/quick_start-test-reference.ipynb.

docs/specs/TST/TST-008.md docs/specs/TST/assets/quick_start-test-reference.ipynb

Parent links: SRS-015 Jupyter Notebook frontend

Child links: TRA-011 TCER: Jupyter Notebook frontend

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Test (T)
release alpha
complexity 2
test_data see referenced files
version 0.1

12 Test ETL logging TST-012

Validate the logging feature of the ETL subsystem.

Preconditions and setup actions

  • Access to source code of SATRAP-DL
  • Access to SATRAP-DL deployment artifacts
  • Access to the internet or a pre-downloaded copy of MITRE ATT&CK data sets in STIX 2.1, e.g., the enterprise TTPs
  • TypeDB Docker container pulled and running using the init-satrap.sh script
  • SATRAP Docker network created using the init-satrap.sh script
  • SATRAP volume for persistent TypeDB storage created using the init-satrap.sh script
  • Docker Engine (or daemon) running with the right privileges for the testing user
  • TypeDB Studio version 2.28.6 installed (alternatively you can interact with the TypeDB backend directly via its CLI)
  • A plain/empty project created in TypeDB Studio
  • SATRAP Docker container created using the build-satrap.sh script

Test dependencies

  • TST-008 executed successfully

Test steps

  1. Run ./satrap.sh etl to launch the default ETL job, fetching a MITRE ATT&CK Mobile data set.

Expected outcome

  1. Check the generated log in the satrap/assets/logs folder (under date folders and timestamped files according to ETL execution time) to validate the following:
  • a log entry is generated at the beginning of the job, indicating the start time
  • each log entry recording an event comes with a log level: DEBUG, INFO, WARNING, ERROR, CRITICAL
  • there is at least a log entry for each ETL phase (i.e., extraction, transformation and loading) describing the status in terms of success/failure and some minimal hint or additional information explaining or complementing the execution status.

Parent links: SRS-033 Functional ETL events logging

Child links: TRA-012 TCER: ETL logging

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Test (T)
release alpha
complexity 2
test_data see referenced files
version 0.1

13 Inspect settings for CM TST-013

Inspect the centralized settings file to verify that some of its content is read from a user-controller configuration management file allowing configuration management without requiring software rebuild.

Preconditions and setup actions

  • Access to the SATRAP-DL source code

Test steps

  1. Navigate to the settings.py file at satrap/settings.py.
  2. Navigate to the YAML configuration management file satrap/assets/satrap_params.yml exposed to and managed by the user.
  3. Check that the YAML file is read into memory (e.g., in a Python dictionary).
  4. Check that at least one parameter in settings.py is read from the in-memory copy of the satrap_params.yml file.

Expected outcome

  1. At least one entry containing a runtime variable assignment making use of the in-memory copy of the configuration/parameters YAML file, e.g.,
VARIABLE = satrap_parameters_dictionary.get('key-1').get('key-2')

satrap/assets/satrap_params.yml satrap/settings.py

Parent links: SRS-041 Configuration management mechanism

Child links: TRA-013 TCER: CM settings

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Inspection (I)
release alpha
complexity 2
test_data see referenced files
version 0.1

14 Test command line interface (CLI) TST-014

Test that a command line interface is implemented and that it provides at least the commands specified in the software requirement specification (SRS) this test traces to.

Preconditions and setup actions

  • Access to source code of SATRAP-DL
  • Access to SATRAP-DL deployment artifacts
  • Access to the internet or a pre-downloaded copy of MITRE ATT&CK data sets in STIX 2.1, e.g., the enterprise TTPs
  • TypeDB Docker container pulled and running using the init-satrap.sh script
  • SATRAP Docker network created using the init-satrap.sh script
  • SATRAP volume for persistent TypeDB storage created using the init-satrap.sh script
  • Docker Engine (or daemon) running with the right privileges for the testing user
  • A plain/empty project created in TypeDB Studio
  • SATRAP Docker container created using the build-satrap.sh script

Test dependencies

  • TST-008 executed successfully

Test steps

  1. Run ./satrap.sh rules
  2. Run ./satrap.sh stats
  3. Run ./satrap.sh techniques
  4. Run ./satrap.sh mitigations
  5. Run ./satrap.sh search campaign--0c259854-4044-4f6c-ac49-118d484b3e3b
  6. Run ./satrap.sh info_mitre T1027.001

Expected outcome

  1. The execution of this step prints out the following
Inference rules defined in the knowledge base:
targeting-via-attribution
course-of-action-for-intrusion-set
usage-via-attribution
transitive-use
  1. The execution of this step prints out the following
+-----------------------+------------------------+
| STIX Domain Objects   |   Total in the CTI SKB |
+=======================+========================+
| course-of-action      |                    285 |
+-----------------------+------------------------+
| attack-pattern        |                    668 |
+-----------------------+------------------------+
| malware-family        |                    624 |
+-----------------------+------------------------+
| campaign              |                     34 |
+-----------------------+------------------------+
| tool                  |                     89 |
+-----------------------+------------------------+
| identity              |                      1 |
+-----------------------+------------------------+
| intrusion-set         |                    170 |
+-----------------------+------------------------+
  1. The execution of this step prints out the following:

See docs/specs/TST/assets/satrap-cli-techniques-evidence.txt

  1. The execution of this step prints out the following

See docs/specs/TST/assets/satrap-cli-mitigations-evidence.txt

  1. The execution of this step prints out the following
+---------------------+---------------------------------------------------------+
| Property            | Value                                                   |
+=====================+=========================================================+
| type                | campaign                                                |
+---------------------+---------------------------------------------------------+
| first-seen          | 2022-10-01 04:00                                        |
+---------------------+---------------------------------------------------------+
| created             | 2024-06-10 18:57                                        |
+---------------------+---------------------------------------------------------+
| name                | KV Botnet Activity                                      |
+---------------------+---------------------------------------------------------+
| last-seen           | 2024-01-01 05:00                                        |
+---------------------+---------------------------------------------------------+
| alias               | KV Botnet Activity                                      |
+---------------------+---------------------------------------------------------+
| description         | [KV Botnet                                              |
|                     | Activity](https://attack.mitre.org/campaigns/C0035)     |
|                     | consisted of exploitation of primarily “end-of-life”    |
|                     | small office-home office (SOHO) equipment from          |
|                     | manufacturers such as Cisco, NETGEAR, and DrayTek. [KV  |
|                     | Botnet                                                  |
|                     | Activity](https://attack.mitre.org/campaigns/C0035) was |
|                     | used by [Volt                                           |
|                     | Typhoon](https://attack.mitre.org/groups/G1017) to      |
|                     | obfuscate connectivity to victims in multiple critical  |
|                     | infrastructure segments, including energy and           |
|                     | telecommunication companies and entities based on the   |
|                     | US territory of Guam. While the KV Botnet is the most   |
|                     | prominent element of this campaign, it overlaps with    |
|                     | another botnet cluster referred to as the JDY           |
|                     | cluster.(Citation: Lumen KVBotnet 2023) This botnet was |
|                     | disrupted by US law enforcement entities in early 2024  |
|                     | after periods of activity from October 2022 through     |
|                     | January 2024.(Citation: DOJ KVBotnet 2024)              |
+---------------------+---------------------------------------------------------+
| revoked             | false                                                   |
+---------------------+---------------------------------------------------------+
| modified            | 2024-10-03 10:11                                        |
+---------------------+---------------------------------------------------------+
| stix-id             | campaign--0c259854-4044-4f6c-ac49-118d484b3e3b          |
+---------------------+---------------------------------------------------------+
| spec-version        | 2.1                                                     |
+---------------------+---------------------------------------------------------+
| created-by          | The MITRE Corporation                                   |
+---------------------+---------------------------------------------------------+
| external-references | ['Lumen KVBotnet 2023', 'mitre-attack', 'DOJ KVBotnet   |
| by                  | 2024']                                                  |
+---------------------+---------------------------------------------------------+
  1. The execution of this step prints out the following
+---------------------+---------------------------------------------------------+
| Property            | Value                                                   |
+=====================+=========================================================+
| type                | attack-pattern                                          |
+---------------------+---------------------------------------------------------+
| created             | 2020-02-05 14:04                                        |
+---------------------+---------------------------------------------------------+
| name                | Binary Padding                                          |
+---------------------+---------------------------------------------------------+
| description         | Adversaries may use binary padding to add junk data and |
|                     | change the on-disk representation of malware. This can  |
|                     | be done without affecting the functionality or behavior |
|                     | of a binary, but can increase the size of the binary    |
|                     | beyond what some security tools are capable of handling |
|                     | due to file size limitations.   Binary padding          |
|                     | effectively changes the checksum of the file and can    |
|                     | also be used to avoid hash-based blocklists and static  |
|                     | anti-virus signatures.(Citation: ESET OceanLotus) The   |
|                     | padding used is commonly generated by a function to     |
|                     | create junk data and then appended to the end or        |
|                     | applied to sections of malware.(Citation: Securelist    |
|                     | Malware Tricks April 2017) Increasing the file size may |
|                     | decrease the effectiveness of certain tools and         |
|                     | detection capabilities that are not designed or         |
|                     | configured to scan large files. This may also reduce    |
|                     | the likelihood of being collected for analysis. Public  |
|                     | file scanning services, such as VirusTotal, limits the  |
|                     | maximum size of an uploaded file to be                  |
|                     | analyzed.(Citation: VirusTotal FAQ)                     |
+---------------------+---------------------------------------------------------+
| revoked             | false                                                   |
+---------------------+---------------------------------------------------------+
| modified            | 2023-03-30 21:01                                        |
+---------------------+---------------------------------------------------------+
| stix-id             | attack-pattern--5bfccc3f-2326-4112-86cc-c1ece9d8a2b5    |
+---------------------+---------------------------------------------------------+
| spec-version        | 2.1                                                     |
+---------------------+---------------------------------------------------------+
| created-by          | The MITRE Corporation                                   |
+---------------------+---------------------------------------------------------+
| external-references | ['ESET OceanLotus', 'Securelist Malware Tricks April    |
| by                  | 2017', 'mitre-attack', 'VirusTotal FAQ']                |
+---------------------+---------------------------------------------------------+

docs/specs/TST/assets/satrap-cli-techniques-evidence.txt docs/specs/TST/assets/satrap-cli-mitigations-evidence.txt

Parent links: SRS-042 Command line interface (CLI)

Child links: TRA-014 TCER: SATRAP CLI

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Test (T)
release alpha
complexity 2
test_data see referenced files
version 0.1

15 Verify open-source TIP integration TST-017

This test case is aimed at validating the adoption of open-soure TIPs by the SATRAP design.

Preconditions and setup actions

  • Access to the SATRAP-DL system concept documents

Test steps

  1. Review the SATRAP-DL system concept documents to confirm that SATRAP adopts both MISP and OpenCTI as open-source TIPs (Threat Intelligence Platform) to manage cyber threat intelligence content and maintain the CyFORT CTI repository.

Expected outcome

  1. Embedded in test steps

Parent links: SRS-044 Open-source TIP integration

Child links: TRA-015 TCER: Open-source TIP adoption

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Review of design (R)
release alpha
complexity 1
test_data see referenced files
version 0.1

16 Verify release and licensing TST-018

Verify the release model and licensing approach adopted for SATRAP-DL.

Preconditions and setup actions

  • Access to the SATRAP-DL source code

Test steps

  1. Verify that the source code of SATRAP-DL is released on GitHub via a public repository.
  2. Verify that 3rd-party libraries used in SATRAP-DL, if any, have open source licenses that do not restrict the privileges granted by the license selected for SATRAP-DL.

Expected outcome

Embedded in test steps.

Parent links: SRS-026 Public release, SRS-027 Open-source licensing

Child links: TRA-016 TCER: release + licensing

Attribute Value
platform GNU/Linux (Dockerized SATRAP deployment environment)
execution_type Manual
verification_method Inspection (I)
release alpha
complexity 1
test_data see referenced files
version 0.1