Add SAST/DAST into the testing pipeline #5

Open
opened 2023-02-22 22:17:42 -06:00 by DarkFeather · 2 comments
Owner

We should add SAST as part of a universal testing framework on all packages prior to delivery. semgrep is a freeware option already in the AUR.

We should also consider adding some kind of DAST pipeline with ossf/package-analysis, though this will require including a Docker environment for testing.

SAST should get implemented first, and then DAST can follow.

We should add SAST as part of a universal testing framework on all packages prior to delivery. [semgrep](https://aur.archlinux.org/packages/semgrep-bin) is a freeware option already in the AUR. We should also consider adding some kind of DAST pipeline with [ossf/package-analysis](https://github.com/ossf/package-analysis), though this will require including a Docker environment for testing. SAST should get implemented first, and then DAST can follow.
Author
Owner

This replaces AniNIX/Wiki#4.

Potential tools:

This replaces AniNIX/Wiki#4. Potential tools: * [Bandit](https://pypi.org/project/bandit/) for SAST * [Zed Attack Proxy](https://www.zaproxy.org/) for DAST * [DefectDojo](https://github.com/DefectDojo/django-DefectDojo)
Author
Owner

I think we'll opt for semgrep + bandit as the SAST pair -- maat will be modified to run semgrep scan and include both as dependencies on the package. We'll introduce a new column on the Maat landing page with scan results. If a .bandit file exists, we'll also run the bandit test battery on the included files. Pass/fail will be based on the number of findings from both tools.

We'll just integrate a ZAP workflow into ongoing pentests -- I don't see the value in burning the compute cycles on ongoing DAST testing on production services. Perhaps another project will fork some automation of our pentests.

I think we'll opt for semgrep + bandit as the SAST pair -- `maat` will be modified to run `semgrep scan` and include both as dependencies on the package. We'll introduce a new column on the Maat landing page with scan results. If a `.bandit` file exists, we'll also run the bandit test battery on the included files. Pass/fail will be based on the number of findings from both tools. We'll just integrate a ZAP workflow into ongoing pentests -- I don't see the value in burning the compute cycles on ongoing DAST testing on production services. Perhaps another project will fork some automation of our pentests.
Sign in to join this conversation.