feat(stesol-580): add blackduck workflow - #131
Conversation
Co-authored-by: NeethuESim <3488970+NeethuESim@users.noreply.github.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
brikin01
left a comment
brikin01
left a comment
There was a problem hiding this comment.
Looks pretty good, just a few small changes/questions!
…into stesol-580-blackduck-sbom
…into stesol-580-blackduck-sbom
…into stesol-580-blackduck-sbom
…into stesol-580-blackduck-sbom
…into stesol-580-blackduck-sbom
…into stesol-580-blackduck-sbom
…into stesol-580-blackduck-sbom
…into stesol-580-blackduck-sbom
brikin01
left a comment
brikin01
left a comment
There was a problem hiding this comment.
Thanks for all the changes, seems to be in a pretty good spot!
I left a few comments about policy-failure behavior and cleaning up the temporary secure-build configuration.
This looks like it covers the initial Black Duck setup shared by STESOL-576 and STESOL-580. I’m assuming the release-evidence side of STESOL-580, e.g. generating the complete SBOM for what we actually ship, will come in a follow-up PR tied into the release workflow. Is that what you had in mind?
| ### Mark build status if policy violating issues are found | ||
| mark_build_status: 'success' |
There was a problem hiding this comment.
Why do we mark the build status as success? I would think a violation would cause a failure?
There was a problem hiding this comment.
You are right, I will add the failure condition based on severity detected.
| branches: [ "main", "secure-build" ] # TODO: remove "secure-build" after merge into main | ||
| pull_request: | ||
| # The branches below must be a subset of the branches above | ||
| branches: [ "main", "secure-build" ] # TODO: remove "secure-build" after merge into main |
There was a problem hiding this comment.
We should be good to delete secure-build now (and also need to change the target branch of the PR to main)
There was a problem hiding this comment.
I wasn't sure on this, let me check in slack. I can then directly create this PR against main instead of merge into secure build
| github_token: ${{ secrets.GITHUB_TOKEN }} | ||
|
|
||
| ### Mark build status if policy violating issues are found | ||
| mark_build_status: 'success' |
There was a problem hiding this comment.
Same question as previous
| - name: Upload Black Duck SARIF | ||
| if: ${{ github.event_name != 'pull_request' }} |
There was a problem hiding this comment.
If we do change policy violations to fail the scan, should this step use an always()/!cancelled() condition so the SARIF report is still uploaded and the findings remain visible?
There was a problem hiding this comment.
Yes, will make sure we have report generated even after policy violation. I will open another PR for the policy violations.
Yes, this PR only covers the initial integration. Will open incremental PRs for the remaining items. |
Add blackduck workflow. Scan resulting from PR merge will be available at Arm BlackDuck UI - https://arm.app.blackduck.com/api/risk-profile-dashboard