My understanding is that Brazil's government uses CloudFlare because its sites kept falling to DDOS attacks it couldn't block. If that's accurate, blocking CloudFlare would open the government to DDOS attacks again.
Which brings up an interesting question of it someone in the US on a work visa is permitted to participate in a work stoppage. Would going on strike be considered a period of unemployment that puts them on the clock for getting deported?
Just one person's experience but when I was younger, I worked for several years at both a non-union grocery store and a unionized store in different cities. Working union was much better but part of that was the quality of co-workers was better. At the non-union store, I can see why unionization on the surface would be unappealing since there were lots of low quality employees. If you're someone who does their assigned work and see other slacking off constantly and constantly screwing things up, hearing the typical union messages of solidarity isn't going to be appealing. You have to be able to view things in the context of unionization of the company also making the jobs more appealing to a better quality worker. In my n=1 opinion, the non-union chain lost lots of money through poor quality labor and might have been better off with high labor costs that would be offset by higher quality labor but I have no way of actually being able to quantify that to determine if it would be true.
At both the union and non-union stores there was a perception that union dues were used by union officials more for their own enrichment than for the benefit of members. Having worked at the non-unionized store first, the better wages and benefits easily outweighed the cost of union dues, but some of that could also have been due to the location in a more affluent area.
The best companies to hit would be those foolish enough to not suspect their code is insecure because all software development produces vulns. Off prem scanning is a big issue in the AppSec space and vendors handle it in various ways, mostly through promises and documented processes, neither of which mean much if the vendor is a front for an intelligence agency or had otherwise been captured.
There are some free tools out there but most do lag behind the industry as a whole by quite a bit. There's also lots of abandoned free tools out there cluttering up the space. Plenty started with good intentions that now give a false sense of security. There's also lots of snake oil in the paid space. Doing one's homework really helps here and you'd be surprised how many tools fail miserably during a simple proof of concept test, which is probably why more and more vendors try to avoid them.
Finding SQL Injection is pretty trivial for SAST tools. The difficulty is what happens next. After whatever tool finds several thousand SQLI vulns in a Cold Fusion application from 2001 that hasn't been touched in over a decade, someone must be identified to take responsibility for changing the code, testing it, and deploying it. Even if the tool can change the code, no one will want to take responsibility for changes made to an application that has quietly running correctly since before most of their department has been at the company using an ancient technology that no one has experience with deploying into production. This is where so many vulns live.
Shift left and modern development patterns can catch a very large amount of known vulns so in newer applications things become mostly about fixing newly discovered vulns and doing it in an active development cycle. It's the older code that's the real scary monster and identifying the vulns is the least scary part of the process to get them remediated and put into production.
Anything that reduces false positives is good, especially if it does so without also making a significant reduction in identified true positives, but none of that changes the fact that it is the low hanging fruit of the system.
Totally agree. We have a term for it "Dev confidence". Devs really don't want to touch something that's been working for a long time, especially in a codebase they're not familiar with. The more removed the dev from the code they're working on + the length it's been running, the lower their confidence. We built in mechanisms to do a number of checks on our fixes to try to our best ability to make sure something doesn't break.
On false positives, we introduced false positive detection using AI & static analysis because of the exact issue you're highlighting.
Far less harmful but I've had Bing chat give me a wrong solution to a programming problem it pulled from Stack Overflow because it confused the code in the question with being an answer to the question. Guilt and innocence by association seems to be something it is prone to without understanding context.
I'd argue that no other thing, apart from information, is transported as easily as electricity, once the grid exists. Sure, there are capacity limits, but I doubt that shutting down crypto mining would cause problems to the grid.
I recently read that some are thinking about connecting the US with Europe via DC cabling.
Here's a related, old article: "Submarine power cable between Europe and North America: A techno-economic analysis" (2018)
• Developed a 2030 power dispatch model of Europe and North America (NA).
• Identified socio-economic benefits of European-NA electricity trading through a HVDC cable.
• A 4000 MW cable increases social welfare by 177 M€ on an annual basis.
• This benefit for society is sufficient to cover the investment costs.
reply