Qt & Cyber Security (Discussion): Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 10: Line 10:
by Vladimir
by Vladimir


- how can users and customers check if a given CVE is fixed or which CVE have been fixed in a given version of Qt
* How can users and customers check if a given CVE is fixed or which CVE have been fixed in a given version of Qt
    - a good way would be to use JIRA since most CVE cases are listed there. A filter that provides a report can be exported
** a good way would be to use JIRA since most CVE cases are listed there. A filter that provides a report can be exported
- We need to create a software BOM for Qt, ideally, in a machine-readable format
* We need to create a software BOM for Qt, ideally in a machine-readable format
- With this list, we could use specialized scanners to search and alert about CVE-related changes
* With this list, we could use specialized scanners to search and alert about CVE-related changes
- Black Duck does not seem a good tool for this. It does not provide sufficiently reliable results
* Black Duck does not seem a good tool for this. It does not provide sufficiently reliable results
- we should reduce the chances that we introduce something that can become a security issue. Does the Security Review help here
* we should reduce the chances that we introduce something that can become a security issue. Does the Security Review help here
- How to draw a border where the API user starts to be reponsible to harded an implmentation on top of Qt
* How to draw a border where the API user starts to be responsible to harden their implementation on top of Qt


Action points:
Action points:
- make sure to have all maintainers on the security list
* make sure to have all maintainers on the security list
- update sec. relevant changes in 3rd parties in docs
* update sec. relevant changes in 3rd parties in docs
- try to create such a JIRA filter and see how its report looks like
* try to create such a JIRA filter and see how its report looks like
- check the project https://snyk.io/
* check the project https://snyk.io/
- central page to copy and page relevant CVE emails  
* central page to copy and page relevant CVE emails  
- Qt Security Overview page
* Qt Security Overview page
- It was mentioned in the main talk: we need to disable approver accounts which are not in use for a given (long) time
* It was mentioned in the main talk: we need to disable approver accounts which are not in use for a given (long) time

Revision as of 12:38, 1 December 2023


Session Summary

This is a follow-up session for the main talk in the keynote slot in the morning

Session Owners

Kai Koehne

Notes

by Vladimir

  • How can users and customers check if a given CVE is fixed or which CVE have been fixed in a given version of Qt
    • a good way would be to use JIRA since most CVE cases are listed there. A filter that provides a report can be exported
  • We need to create a software BOM for Qt, ideally in a machine-readable format
  • With this list, we could use specialized scanners to search and alert about CVE-related changes
  • Black Duck does not seem a good tool for this. It does not provide sufficiently reliable results
  • we should reduce the chances that we introduce something that can become a security issue. Does the Security Review help here
  • How to draw a border where the API user starts to be responsible to harden their implementation on top of Qt

Action points:

  • make sure to have all maintainers on the security list
  • update sec. relevant changes in 3rd parties in docs
  • try to create such a JIRA filter and see how its report looks like
  • check the project https://snyk.io/
  • central page to copy and page relevant CVE emails
  • Qt Security Overview page
  • It was mentioned in the main talk: we need to disable approver accounts which are not in use for a given (long) time