You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hooks are not starting when scan has "Errored" state #2105
Hi @Weltraumschaf,
The issue you mentioned does not seem to be related to the issue I'm reporting. Even if the scan is set to "Failed" or "Errored" or any other state, it should eventually trigger the Hooks.
This is acutally the intended behaviour. ScanCompletionHooks are only triggered for successful scans, as failed scans are never counted as completed.
This was done to make the development of the hooks more straight forward and more safe. Hooks can can rely on the fact that both findings and raw results are available and don't need to handle failure cases where either of them is missing.
Running code / hooks on failed scans would be something that we would like to support (optionally, so that existing hooks are not broken) but we haven't yet required it ourself.
Ideal process for it would be to open up a feature request issue here for it and a pull request with a draft Architecture Decision Record (ADR) detailing what changes to the ScanCompletionHook custom resource would be required. Ideally already with the implementation in the operator :)
@Dstklr not with hooks or other secure odeBox mechanisms right now.
So the best way right now is to rely on error logging or by alerting on missing ingested data in elasticsearch / defectdojo.
Or depending on your setup and how you create the scans, by using kubectl to await the scans completion and then handle the error in the script which creates the scans.
Of course this is not ideal and having hooks be able to optionally also handle error cases (when it makes sense for the hook) would be an awesome addition to the secureCodeBox.
Activity
Weltraumschaf commentedon Nov 20, 2023
Hi @Dstklr,
thank you for filingthis issue. We'll discuss this in the team.
Weltraumschaf commentedon Nov 21, 2023
Relates to #238
Dstklr commentedon Nov 22, 2023
Hi @Weltraumschaf,
The issue you mentioned does not seem to be related to the issue I'm reporting. Even if the scan is set to "Failed" or "Errored" or any other state, it should eventually trigger the Hooks.
J12934 commentedon Nov 28, 2023
Hi @Dstklr
This is acutally the intended behaviour. ScanCompletionHooks are only triggered for successful scans, as failed scans are never counted as completed.
This was done to make the development of the hooks more straight forward and more safe. Hooks can can rely on the fact that both findings and raw results are available and don't need to handle failure cases where either of them is missing.
But this behaviour is definitly not described properly in the related API docs page for the https://www.securecodebox.io/docs/api/crds/scan-completion-hook so I'd keep this bug ticket open to resolve / clarify it in the docs.
Running code / hooks on failed scans would be something that we would like to support (optionally, so that existing hooks are not broken) but we haven't yet required it ourself.
Ideal process for it would be to open up a feature request issue here for it and a pull request with a draft Architecture Decision Record (ADR) detailing what changes to the ScanCompletionHook custom resource would be required. Ideally already with the implementation in the operator :)
Dstklr commentedon Nov 28, 2023
Hi @J12934,
if this is the case, is there a way to get some sort of notification/indication when a scan fails without manually check it ?
J12934 commentedon Dec 28, 2023
@Dstklr not with hooks or other secure odeBox mechanisms right now.
So the best way right now is to rely on error logging or by alerting on missing ingested data in elasticsearch / defectdojo.
Or depending on your setup and how you create the scans, by using kubectl to await the scans completion and then handle the error in the script which creates the scans.
Of course this is not ideal and having hooks be able to optionally also handle error cases (when it makes sense for the hook) would be an awesome addition to the secureCodeBox.