Create automated demo environment and test plan for offline/air-gapped deployments
Test Plan
Introduction
The Secure Stage is documenting how to enable its features in an offline or air-gapped environment. This is a large effort calling for a demo environment which can be regularly spun up and torn down.
Further, verification that the environment is truly air-gapped should be automated.
Scope
- No access to public internet resources from the GitLab environment itself.
- Access to other resources, such as a private repository in the same network, is acceptable.
- Secure features, including the docker containers for all scanners should be enabled and working within a sample project and pipeline.
Tasks
Test Plan
Introduction
It shall be tested that analyzers can function correctly within an airgapped environment.
The provisioning, installation, airgapping and validation of an airgapped environment shall be automated.
Objectives and Tasks
Objectives
The verification shall be carried out by the Quality team members - Will Meek and Grant Young.
This issue ticket is used as a vehicle for communication.
Tasks
This test plan shall identify the tasks to test.
### Scope
The automated environment provisioning was initially to be a ruby script utilising fog, but will now likely be a specialised variant of the performance environment builder tool.
The following shall be tested by running analysers against language test projects
| .NET | Security Code Scan |
|---|---|
| Any | Gitleaks and TruffleHog |
| Apex (Salesforce) | pmd |
| C/C++ | Flawfinder |
| Elixir (Phoenix) | Sobelow |
| Go | Gosec |
| Groovy (Ant, Gradle, Maven and SBT) | SpotBugs with the find-sec-bugs plugin |
| Java (Ant, Gradle, Maven and SBT) | SpotBugs with the find-sec-bugs plugin |
| JavaScript | ESLint security plugin |
| Kubernetes manifests | Kubesec |
| Node.js | NodeJsScan |
| PHP | phpcs-security-audit |
| Python (pip) | bandit |
| React | ESLint react plugin |
| Ruby on Rails | brakeman |
| Scala (Ant, Gradle, Maven and SBT) | SpotBugs with the find-sec-bugs plugin |
| TypeScript | TSLint config security |
Together with:
| Analyzer |
|---|
| klar |
| gemnasium |
| gemnasium-maven |
| gemnasium-gradle-plugin |
| gemnasium-python |
| retire.js |
| secrets |
| security-code-scan |
Testing Strategy
Unit Testing
Unit testing may not be applicable unless it is required to prove out a particular analyzer feature.
#### System and Integration Testing
System testing shall prove out the analyzer functionality on the airgapped systems, running a CI pipeline against the test projects.
Performance Testing
Priority is functional rather than performance testing. However the environment builder could be utilised if required to give performance figures at a later stage.
User Acceptance Testing
The environment shall be demoed to end users for feedback.
Automated Regression Testing
Existing tests can be leveraged where required.
Environment Requirements
Google Cloud shall be used for VMs. Airgapping can be simulated using iptables either blacklisting certain domains, or by blocking all traffic whitelisting ports (HTTP(S)/SSH).
Control Procedures
Problem Reporting
Issues shall be raised when observed, providing as much detail as possible, with reproducible steps, and environment details.
This should also be mentioned in the appropriate slack channel.
Merge Requests
Merge requests should be made against the appropriate product/repository.
Features to be Tested
- Environment can be provisioned and installed
- Environment proven out to be airgapped
- Analysers execute in an airgapped system
Features not to be Tested
- Docker in Docker
Dependencies
Access to appropriate Google Cloud projects
### Risks / Assumptions
Airgapped-ness shall be simulated, as an entirely airgapped system does not allow any remote access for observation. QA team member Will Meek is still ramping up on knowledge and GitLab skillsets.