Hey everyone, I'm Lee, a Product Manager in the Security department here at Atlassian. I wanted to let you know that we've made a few updates to the format of our security bulletins as a first step to address the heightened volume of support tickets and questions ("Is my version affected?") that we regularly receive regarding our security bulletins. I'm also here to let you know that we are actively seeking feedback from the community for these bulletin updates and the various security resources Atlassian provides.
First, let's review the notable updates this month's Security Bulletin:
We believe these enhancements will make it easier to quickly identify the impact of vulnerabilities and take appropriate action to secure your systems without needing to file a support ticket to answer your security bulletin-related questions.
We look to take an iterative approach based on feedback to improve our bulletins, advisories, and the various security resources Atlassian provides. I would appreciate any feedback you might have for us, feel free to reach out! Thank you, I'm looking forward to working with this community!
@Lee BergI just checked https://www.atlassian.com/trust/data-protection/vulnerabilities and it seems that the data behind this api is not updated yet. Confluence Data Center 7.19.18 is listed as not affected by any vulnerability there (is is not listed) while it is clearly marked as affected in the bulletin.
Can you elaborate on why the data is still outdated? The api is relatively useless if it can't be trusted.
I think I have used the API wrong. For 7.19.19 the CVE CVE-2023-2976 is listed as FIXED in the API Response and the GUI correctly calculates, that 7.19.18 therefore must have been affected, even if the CVE-ID itself is not listed as AFFECTED for 7.19.18. That is kind-of confusing but at least the data is not outdated as I thought.
I just gave the portal a look and I did manage to get a result for Confluence Data Center and 7.19.18 - I did notice the drop down was not populated and I had to "Manually enter" this version.
The Portal/API does only start retrieving new data after we publish our advisory artifacts so sometimes there can be a delay between the portal having data and our bulletins going live but this should never exceed one hour.
Do you happen to know exactly when you tried using the portal? I'd like to have my engineering team investigate to see if there was an error on our api log for the time window you tried to lookup this data. Thank you!
@Lee BergSo I reverse engeneered the Code that powers the Vulnerability Portal and found my source of confusion. Especially it is this piece of Code that I have not found documented anywhere else:
https://gist.github.com/MaZderMind/bf704442bf3e0ac905e3ad5bc96f4100
It interprets AFFECTED and FIXED versions and calculates for which versions before the AFFECTED and between the AFFECTED and FIXED version a Product-Version is deemed vulnerable.
For Example for CVE-2024-21674 the API lists Confluence 7.19.0 as AFFECTED and 7.19.18
The above Code also calculates 7.0.0, 7.17.0, 7.17.1, 7.19.0 and 7.19.17 to be affected. You can verify these versions by typing them into the vulnerability portal together with the CVE-ID and the Product Name.
I would rather prefer the API to list all affected versions and not require any interpretaton on the client side. This would also reduce quite a bit of confusion because the Vulnerability Portal's results does not match up what can be retrieved from the API. As an alternative I would suggest to document the Algorithem on the API Documentation Page and provide tested implementations in the usual languages.
Thank you for listening to us. We're in this boat together, trying to keep our customers safe.
I like the changes - definitely easier to parse. I now have a question about how to know the status of versions that don't appear in the Affected column but are not in the Fixed column either? (example Jira 9.12.2 or Confluence 8.5.5)
Great Question @Sol Day - we've actually just updated the tables to account for these as well. They should be considered "Fixed Version" and have been updated as such. Thanks for the quick reply!
Aren't we having just too many and too frequent security vulnerabilities these days ?
This is the point. Most of them could be avoided by having at least a minimum quality control. Especially things like shipping backdoors with trashmail accounts like it happened in confluence is just a joke for "enterprise software" with "enterprise prisings".
Managing how the bunch of monthly RCEs and other vulnerabilities are presented doesn't solve the underlying problems causing the monthly (sometimes weekly) security holes. It just makes it a bit less worse.
Hi @Lee Berg
Assets Discovery (CVE-2024-21682) is missing from the vulnerability portal and corresponding REST API.
The improved table layout in CAC makes sense so far. The last missing piece here would be if the Confluence theming in general can be improved so that the content has more space. ~600px and tables isn't perfect :D
Kind Regards,
Tim
PS: Some feedback on Feedback about Security Vulnerability API would be highly appreciated.
Hey Tim! Wow this API feedback post is great - apologies for missing this, thanks for highlighting it. I'll be setting aside some time to review your post in detail and will reply / reach out on your post - huge thanks for taking the time to write that up! I've been looking for feedback from folks digging into the api data!
Regarding Assets Discovery (CVE-2024-21682) missing from the vulnerability portal and corresponding REST API - yes this is known on our side, first party apps have a few field differences in their data preventing us from displaying on the transparency portal and api. This particular item was a last minute addition to the bulletin this month so we did not have time to prep an update for the portal. We are looking to update the portal and API to be able to support this type of idea (first part apps)
The confluence theming is indeed problematic!. I actually have a few conversations ongoing with the confluence.com team to see what we can do for our March bulletin. It is well known on my team that the 600px limitation is NOT IDEAL and on modern desktop resolutions and on mobile... well, let's just say its worse :)
Hello @Lee Berg ,
I think there is a mistake on Jira 9.4.15. My understanding of the bulletin is that it should be clear from any vulnerability and instead of that the vulnerability portal shows it affected by even more vulnerabilities than 9.4.14.
PS: It would be really great if you could ensure all available release appears in the "Affected versions" field.
I also had this issue today. That is; searching for a specific version will list CVEs that are not related to the version I am searching for. At least not if I check the details for the CVE.
Also, the Vulnerability Portal lists fewer vulnerabilities that the security bulletin. IMO the vulnerability portal can't be trusted. I would rather rely on the fixed versions in the sec bulletins.
Hey @HAEGELIN Sacha thanks for providing this scenario and screenshots! this is very helpful to help me and my team test/replicate.
Testing exactly as you have specified here: Jira Software Server 9.4.15 - I seem to be getting the same results... I cannot say why these particular results are being displayed but I can say this for sure looks like a problem/bug to me.
Like @Shroomy mentions in the reply - it does indeed look like is pulling in extra cves, and when I check them, 9.4.15 is NOT in the range.
I'm going to be opening a ticket for my team to investigate and resolve. We've done a fair amount of testing in the past across products & versions and haven't seen this, so I'm really curious what is causing this behavior. I'll reach back out with an update hopefully soon (especially when the issue is resolved)
Regarding: "ensuring all available release appears in the "Affected versions" field."
Yes! We've heard that on this community post and in some tickets that many folks want/need to see these versions in the dropdowns - Makes complete sense. Today we actually source data from our jira.atlassian.com tickets and our bulletins/advisories but we can do a better job by sourcing *all* versions via internal mechanisms.
We also really appreciate the changes! Thank you for your efforts to improve communication.
There seems to be some inconsistency between the Vulnerability Disclosure Portal and the Security Bulletin. This ambiguity creates confusion and can lead to vulnerable systems not being patched.
Here is an example where we could potentially miss out on security vulnerabilities because of issues with the Vulnerability Disclosure Portal.
On 21st of February I checked the Vulnerability Disclosure Portal to see if our instance of Confluence had any vulnerabilities. We were running Confluence Data Center 7.19.18. At the time I could not see this version in the list at all, so I assumed there were no vulnerabilities for this version. Here is a screenshot:
However, upon reading the February 2024 Security Bulletin the following vulnerabilities were listed for Confluence Data Center 7.19.18.
CVE-2024-21678, CVE-2023-5072, CVE-2023-6481, CVE-2023-6378, CVE-2023-46589, CVE-2023-39410, CVE-2023-41835, CVE-2023-2976
The bulletin specifically mentions affected versions "from 7.19.0 (LTS) to 7.19.18 (LTS)". I assume that also means including 7.19.18 or am I wrong? Again, this wording creates ambiguity. Here is a screenshot:
As you can see there seems to be some inconsistency between the Vulnerability Disclosure Portal and the Security Bulletin.
In my opinion the reason why people are confused about which version is affected is because:
1. Atlassian has many different ways of writing (wording) which products are affected instead of adhering to one standard for how these things should be written.
2. Multiple sources of truth. Jira bug tracker, security bulletins, vulnerability portal, CVE listings. This creates confusion whenever there are contradicting information.
Can we trust the Vulnerability Disclosure Portal? If not, what is the point of having it?
Regarding 7.19.18 being missing from the dropdowns:
Yes! That makes complete sense. Today we actually source data from our jira.atlassian.com tickets and our bulletins/advisories data in a method that excluded this version from the dropdown. I have since made a modification to our artifacts that has restored 7.19.18 in the Portal now. That being said we need to do a better job sourcing *all* versions via internal mechanisms so that you can always see valid versions in the drop downs. I will mention that you CAN manually specify versions in the dropdown fields by typing them out, but this is not obvious and not an ideal UX.
Regarding the ranges: "from 7.19.0 (LTS) to 7.19.18 (LTS)".
You did interpret this correctly that 7.19.18 IS Affected.
To write that out it would look like this:
For the Range Starting with 7.19.0 (LTS) and ending with and INCLUDING 7.19.18 (LTS)...
I can take this feedback back to our content design team and see what adjustments we could consider making.
FYI: One thing a bit tricky about this bulletin is that for the 8 Confluence vulnerabilities listed 7 of them have a fixed version of 7.19.18 (or lower) but ONE is fixed at 7.18.19. This is why on the bulletin we only listed one fixed version for the 7.19.19 LTS - as this is the only version that will "Fix" all 8 Vulnerabilities in the bulletin.
Regarding: Can we trust the Vulnerability Disclosure Portal? If not, what is the point of having it?
Absolutely valid point - I appreciate you taking the time here to spell out the difficulties and with your feedback and feedback from fellow community member(s): @HAEGELIN Sacha and @Tim Eddelbüttel - I have some immediate action items for my team. I hope to publish a changelog as a followup response here shortly for what we have done to resolve the issues.
@Lee BergIt seems the change you did to add 7.19.18 to the dropdown now also reveals it in the API as affected. Having the API to trust would be sooo much help in identifying all relevant vulnerable systems. We currently manually copy'n'paste the bulettins' content to a .json to incoorperate into our ISAC system.
Thank you so much for the work and communication effort you put into this.
Peter
The spacing and format is better, but still leaves a lot to be desired.
I dislike reading the versions affected on 2 lines of a bulleted list. More spacing for the columns would make it easier to read being on a single line.
I'm sure there's a reason for this strict width formatting, email/mobile/whatever, but this is just a ton of text in a non-friendly table format.
Hey @Ryan Goodwin - totally agree, the column spacing and overall sizing of the columns is rough and the mobile display is downright BAD.
Internally our draft bulletin copy in Confluence looked quite nice but when published/translated to confluence.com we were a bit surprised to see these issues. In our attempt to be more verbose in the affected version fields we ran head-first into this issue.
I have some conversations ongoing with the confluence.com team to see what we can do for our March bulletin, whether that be applying theme updates to our bulletin pages our even moving away from Tables in our bulletin automation to avoid this issue all together. We will be looking to run some additional tests with our published artifacts on Confluence.com to prevent any bulletin day surprises like this on our side :) Thanks for the feedback and I hope to have a nice crisp more-readable format for next time!
Quick Update: Just wanted to say thanks again to: @Shroomy @HAEGELIN Sacha @Peter Körner for the immediate feedback on the versions.
We have just deployed a small fix to the portal - there was a sorting/semver evaluation issue that has now been corrected. In our investigation my team did also find two tickets from Nov/Dec that we missing 9.4 LTS versions in their Fixed Version for Jira Software - I have corrected these.
In the Scenario @HAEGELIN Sacha called out - PreFix: we saw apx 1 dozen affected CVEs for: "Jira Software" - 9.4.15... Post-Fix this is correctly showing 0 RESULTS (NOT AFFECTED). We will look to tackle some other feedback areas called out in this thread next but just wanted to post a quick update to show that we are committed to resolving issues and respect the work y'all put in to help us out with this one! In the coming week, we have a session internally to review feedback and learnings from the February bulletin and I will definitely be bringing this to the table. Thank You!
Hi @Lee Berg ,
Good change. Is it also possible to add one more column "Mitigation Available" with yes or no value. This will help to know if there are any mitigations available for users who cannot upgrade all of sudden.
Is there a fix for CVE-2024-22257 . 5.15.2 is effected we are on Jira Service Management 5.13.1. and we run Jira Software and Jira Service Management together so the versions have to be the equivalent to each other.
Hey Dan!
Apologies #1
We actually just removed 5.15.2 from the bulletin as it is NOT AFFECTED and is actually a FIXED Version.
Apologies #2
The May bulletin link to this February Post but our latest community post is over here: https://community.atlassian.com/t5/Trust-Security-articles/May-2024-Security-Bulletin/ba-p/2704564#M701
I am puzzled by the latest bulletin for July 2024. It seems to be missing Jira Software versions greater than 9.8.0 except for the 9.12.11 (LTS). Does this mean that versions 9.13.0 through to 9.17.0 are unaffected by this vulnerability.
In all other Bulletins since Feb 2024, the latest version of Jira Software (and its companion Jira Service Management) are mentioned as Fixed Versions.
@Lee Berg The Security bulletins for June 2024 & July 2024 link back to this community post (February). Can you share the links for June & July's community posts here please? Thanks!