Enable additional security and compliance checks

[zabbal]

No description provided.

[codecov-commenter]

Codecov Report

Merging #1749 into master will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1749      +/-   ##
==========================================
- Coverage   84.98%   84.91%   -0.07%     
==========================================
  Files         178      178              
  Lines       12019    12019              
==========================================
- Hits        10214    10206       -8     
- Misses       1805     1813       +8     

Impacted Files	Coverage Δ
src/libaktualizr/package_manager/ostreemanager.cc	78.46% <0.00%> (-1.46%)	⬇️
src/aktualizr_info/main.cc	93.19% <0.00%> (-0.86%)	⬇️
src/libaktualizr-posix/ipuptanesecondary.cc	86.87% <0.00%> (-0.71%)	⬇️
src/libaktualizr/storage/sqlstorage_base.cc	80.27% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 02ff5a1...10b0bb0. Read the comment docs.

[zabbal]

Note to self: this can be greatly optimized by explicitly stating job dependencies. Will try that in next PR.

[pattivacek]

Can you give me a bit more information about what these are actually doing, or how to tell that they are doing meaningful reviews? In particular, the license scanner says "No active and installed package managers found for project." (https://main.gitlab.in.here.com/olp/edge/ota/connect/client/aktualizr/-/jobs/4695378)

[zabbal]

Sure, here's brief overview:

• SAST - static code analysis for potential vulnerabilities (integer, buffer overflow etc)
• Secret-Detection - check for high-entropy strings which could be secrets (tokens, access keys etc)
• Dependency-Scanning - check dependencies versions for know vulnerabilities (CVE)
• License-Scanning - check for licences (code and dependencies)

All those are far from perfect and give false positives or simply fail. They are still under active development. The only mandatory right now is SAST checker while others are expected to become part of recommended battery of tests as they mature. I've just thought it's easier to add them all in one go.

The failing part of the license checker is an attempt to looks up dependencies licenses. The check for our own code license should still work.

[pattivacek]

All those are far from perfect and give false positives or simply fail. They are still under active development.

Okay, thanks for the info. I think this is probably fine, but if they do start yielding lots of unhelpful output, can we switch them to be optional? Or can we put them into a separate phase of the pipeline? I think at the moment it's a bit confusing to have them mixed in with the regular test suite.

[zabbal]

They all are already optional. I can also move them to separate stage or remove completely.

[pattivacek]

They all are already optional.

Oh nice, great! Sorry, I didn't realize that.

I can also move them to separate stage or remove completely.

I think I would prefer if they were bundled as a separate stage from the unit tests.

[zabbal]

I see multiple "dependencies" entries which looks like a misnomer caused by confusing gitlab language. Are those what humans think (this job depends on that job) or it's what gitlab thinks (take artifacts from those jobs only while depending on all the previously defined jobs)? If it's the former than I can greatly simplify and speedup the pipeline by using proper syntax.

[pattivacek]

I see multiple "dependencies" entries which looks like a misnomer caused by confusing gitlab language. Are those what humans think (this job depends on that job) or it's what gitlab thinks (take artifacts from those jobs only while depending on all the previously defined jobs)? If it's the former than I can greatly simplify and speedup the pipeline by using proper syntax.

Oh, interesting! Yes, I agree, it's the former meaning.

[zabbal]

Shall I add commits to this PR or make another one?

[pattivacek]

Shall I add commits to this PR or make another one?

Let's merge this one since it looks good now and then you can make another.