OUTOFSCOPE doesn't seem to be working

[zaproxy]

OUTOFSCOPE doesn't seem to be working

[thc202]

Actually, the OUTOFSCOPE case is not being handled (yet), just IGNORE. This also applies to the full scan.

[acodeninja]

This issue looks to be related to the mainline @zaproxy/actions-common-scans repo.

https://github.com/zaproxy/action-baseline/blob/master/index.js#L47 < only adds -c ${rulesFileLocation} if the plugins variable has a length greater than 0.

the plugins variable is set here https://github.com/zaproxy/action-baseline/blob/master/index.js#L40

the processLineByLine method here https://github.com/zaproxy/actions-common/blob/master/packages/scans/src/action-helper.js#L38 only adds to the return value if you have at least one IGNORE directive in your config file.

I'm not sure that the call to common.helper.processLineByLine is really needed here, and I found it strange that this logic was in place. If the file is invalid for whatever reason I'd expect the zap-baseline.py program to return a non-zero exit code.

As a temporary workaround I've added this line to our own repos baseline config:

# We ignore a non-existent rule here as the github action won't pass this file without it
# See https://github.com/zaproxy/action-baseline/issues/44
-1	IGNORE	(Fix for https://github.com/zaproxy/action-baseline/issues/44)

[pgregory118]

Thanks for nothing

[kingthorin]

Specific to this one, please provide a valid target: "target: 1httpa:----------.com' "

---

Please don't ask questions as issues - the ZAP User Group is a much better place for questions.

If you’re asking about a third party components such as the Jenkins plugin or VSTS plugin please look for their preferred support mechanism as these were not created by and are not supported by the core team.

[kingthorin]

@pgregory118 I've moved the ticket to the appropriate repo. There isn't enough detail in your report to identify an issue aside from the fact that your target appears invalid (yes I understand it isn't full of hyphens but the leading "1" and trailing "a" didn't bode well). Further we have no idea what may have changed between runs or within the environment/code base.

If you can pin point an issue let us know, otherwise it seems like a question to be handled via the User Group.

[erzz]

Would be nice for this to be included - any ideas of timeline?

[dennis-hh]

This issue unfortunately still exists. Also used @acodeninja's workaround.