5 ms·

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

drewcoo 2y ago
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.
- soco 2y ago
  Oh but we do talk and even praise the "move fast break things" - until it's actually broken, that is.
- t_believ-er873 2y ago
  You're right about "Sec" in DevSecOps. Unfortunately, often it’s just about being reactive monitoring. It’s true that monitoring alone doesn’t prevent incidents but rather just tells you after the fact that something has gone wrong. The real challenge is integrating proactive security measures that actually prevent incidents before they occur or measures that can help to handle the consequences, like MFA, encryption, regular backups and their testing, Disaster Recovery, etc.
thanksgiving 2y ago
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.
- albertopv 2y ago
  > Only the developers can decide when a feature is ready It's the business that pays the wages. Also, time to market is most important (for everyone but Apple), coming later with a better product often doesn't mean a viable business. Problem is almost nobody is promoted for maintaining or improving an existing product, no C-level is interested in tech debt management/reduction, anywhere.
  - freilanzer 2y ago
    > It's the business that pays the wages. It's the developers who do the work.
    - Lutger 2y ago
      Everybody does the work. For an enterprise, its administration or HR who actually pay the wages. The business certainly doesn't, they think up the model and the features, the business problems. I find this whole thing very confusing, there are no factions actually and everybody contributes, and has more or less the same outcomes as their ultimate interest. Maybe not the shareholders. Those truly don't do any work at all, but extract value out of the work done by those who are paid a wage. They only bring in capital. The real reason developers should be able to mandate when something is 'good enough' is because it is their expertise, just as 'the business' decides what features should be build (those that solve a business problem). Just like a medical doctor decides on the treatment and not the manager of the hospital. While pumping out features or 'solving business problems' brings in the money, security risks can, at its worst, instantly terminate the whole business. But developers don't want the company to go bankrupt because they spend a year eliminating every risk. Similarly product people won't like their company to die because they squeezed out an extra hour or two out of the sprint by avoiding any security work. A serious enterprise is, or should be, concerned with risks as well as 'velocity'.
- rco8786 2y ago
  TBH, I think this way of thinking is part of the problem. It's not "developers vs the business". Developers are part of the business.
firtoz 2y ago
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...?
CAP_NET_ADMIN 2y ago
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.

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.

soco 2y ago
Oh but we do talk and even praise the "move fast break things" - until it's actually broken, that is.
t_believ-er873 2y ago
You're right about "Sec" in DevSecOps. Unfortunately, often it’s just about being reactive monitoring. It’s true that monitoring alone doesn’t prevent incidents but rather just tells you after the fact that something has gone wrong. The real challenge is integrating proactive security measures that actually prevent incidents before they occur or measures that can help to handle the consequences, like MFA, encryption, regular backups and their testing, Disaster Recovery, etc.

thanksgiving 2y ago

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.

albertopv 2y ago
> Only the developers can decide when a feature is ready It's the business that pays the wages. Also, time to market is most important (for everyone but Apple), coming later with a better product often doesn't mean a viable business. Problem is almost nobody is promoted for maintaining or improving an existing product, no C-level is interested in tech debt management/reduction, anywhere.
- freilanzer 2y ago
  > It's the business that pays the wages. It's the developers who do the work.
  - Lutger 2y ago
    Everybody does the work. For an enterprise, its administration or HR who actually pay the wages. The business certainly doesn't, they think up the model and the features, the business problems. I find this whole thing very confusing, there are no factions actually and everybody contributes, and has more or less the same outcomes as their ultimate interest. Maybe not the shareholders. Those truly don't do any work at all, but extract value out of the work done by those who are paid a wage. They only bring in capital. The real reason developers should be able to mandate when something is 'good enough' is because it is their expertise, just as 'the business' decides what features should be build (those that solve a business problem). Just like a medical doctor decides on the treatment and not the manager of the hospital. While pumping out features or 'solving business problems' brings in the money, security risks can, at its worst, instantly terminate the whole business. But developers don't want the company to go bankrupt because they spend a year eliminating every risk. Similarly product people won't like their company to die because they squeezed out an extra hour or two out of the sprint by avoiding any security work. A serious enterprise is, or should be, concerned with risks as well as 'velocity'.
rco8786 2y ago
TBH, I think this way of thinking is part of the problem. It's not "developers vs the business". Developers are part of the business.

firtoz 2y ago

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...?

CAP_NET_ADMIN 2y ago

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.