Qt & Cyber Security (Discussion): Difference between revisions
Jump to navigation
Jump to search
(Created page with "Category:QtCS2023 ==Session Summary== ==Session Owners== ==Notes==") |
WindJunkie (talk | contribs) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
==Session Summary== | ==Session Summary== | ||
This is the 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 | |||
Latest revision as of 12:38, 1 December 2023
Session Summary
This is the 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