zap-full-scan Report File is not written after full scan completes. No errors reported in the console. baseline scan works fine.
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 15.8k
- Forks
- 2.6k
- Avg merge
- 13h 16m
- Merged PRs (30d)
- 17
Description
Describe the bug
When running the report file is not written
Steps to reproduce the behavior
1: install docker desktop
2: run docker (docker run -v C:\user{username}\Desktop\Work:/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -t https://www.{domain}.com/ -j {domain}_Full_report.json -g gen.conf -quickprogress -v)
3: observe no report file is written to the mounted path
Expected behavior
the file is written or the console outputs an error message explaining what happened
Software versions
I have tried docker desktop and TrueNAS Scale with this and the latest tag. I have the same issue. The file will not write to a mount.
I am using quite a few other scanners that all mount to this folder, and they are able to write the report files just fine.
Screenshots
Errors from the zap.log file
no log file exists in the home directory.
Additional context
I have used the touch command per the documentation to confirm that files are touched, and no errors are output by the console.
I have no issues with running the baseline scan and getting the report to write from the same docker.
Would you like to help fix this issue?
- Yes
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the exact Docker command from the issue and compare its report behavior with the working baseline scan. Start with zap-full-scan.py and the /zap/wrk mount handling; check how the JSON report path is resolved and whether failures are surfaced. Done means the report is written to the mounted path or a useful error is printed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- cli, devops
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100