August 9th, 2024

Number of incidents affecting GitHub, Bitbucket, Gitlab and Jira is rising

Incidents on major development platforms like GitHub, Bitbucket, GitLab, and Jira are rising, with GitHub up 21% in 2023, highlighting security challenges and the need for better collaboration in DevSecOps.

Read original articleLink Icon
Number of incidents affecting GitHub, Bitbucket, Gitlab and Jira is rising

The number of incidents affecting major development platforms such as GitHub, Bitbucket, GitLab, and Jira has been increasing, posing significant challenges for DevSecOps teams. In 2023, GitHub experienced a 21% rise in incidents, with RepoJacking attacks exposing millions of repositories to vulnerabilities. Bitbucket saw a slight decrease in incidents, while Jira users faced a 50% increase, totaling 75 incidents. GitLab reported that 32% of its incidents impacted service performance, with notable disruptions occurring in June and August. Security vulnerabilities, including critical Remote Code Execution flaws, were prevalent across these platforms. Attackers have increasingly exploited GitHub for malicious purposes, using it to host malware and execute commands covertly. The integration of security into the development process remains a challenge, as developers prioritize speed while security teams focus on vulnerability management. This disconnect can lead to data breaches and operational disruptions, emphasizing the need for a collaborative approach to security in the software development lifecycle.

- Incidents affecting GitHub, Bitbucket, GitLab, and Jira are on the rise, with GitHub seeing a 21% increase in 2023.

- RepoJacking attacks have exposed millions of repositories on GitHub to vulnerabilities.

- Jira users experienced a 50% increase in incidents, while GitLab reported significant service performance issues.

- Attackers are using GitHub to host malware and execute commands, complicating threat detection.

- The integration of security in DevSecOps processes remains a challenge due to differing priorities between developers and security teams.

Link Icon 4 comments
By @thanksgiving - 3 months
In my opinion, the only true solution is to slow down “velocity” in development teams. If the developers are to be held responsible for producing good, secure code, Only the developers can decide when a feature is ready, not the business.

If the business wants to dictate deadlines, the business is responsible for security.

Edit: I should say development team to include qa, but we don’t have those anymore at most places.

By @drewcoo - 3 months
The industry response to this seems to be "DevSecOps," where the only real "Sec" is reactionary monitoring. Monitoring doesn't keep incidents from happening. It only raises internal awareness.

This is the best that most separate security teams do, too.

In all fairness, the "DevOps" part of things can manage deploys in ways to minimize exposure. But most teams that I've seen revert to manual "process" whenever something unusual occurs, so forget about the ideal automated responses to problems we were promised when we were trying to automate sysadmins out of their jobs. There are several layers of broken here that we're not allowed to talk about.

By @firtoz - 3 months
I wonder if eventually we'll go back to either "more open" or "more decentralised" versions of these, in the longer term. I know there are quite a few that exist, which is in a way already "somewhat decentralised", but some may need to be more "inter-connected" to at least have some of the core "moat" functionalities of GitHub e.g. "see all things this person worked on", "how active are they in the overall community", etc. I can think of some technical bridges, at least...?
By @CAP_NET_ADMIN - 3 months
Around 2021 a lot of higher-up people at my company pushed for moving from our local Gitlab instance (neatly hidden in our segmented VPN network) to the global one - because that's what all of the cool guys are doing.

I've resisted this, because I know that I can sleep peacefully at night when the inevitable monthly "GitLab Critical Patch Release" email comes.