Yup, I'm sure this is going to end well.
Like 4000 tests a day, always returning green charts, looking great on weekly meetings I'm sure.
They've demanded that we drop the WAF for them (WAF still irks me, it implies you don't know what you're running, but that's another day's topic), so that they can "better test our infrastructure".
They're completely oblivious on how a buffer overflow would be executed, and I'm pretty sure they couldn't tell me what the difference is between http2 and http.
I'm really saddened by the fact that this industry just barely runs from one breach to the next, pretending everything is fine, not understanding any of it and slapping on one-click solutions and pen-testing up the wazoo.
For christ sakes I had to correct a report saying our data was stored in a "community", because it's a third party data centre they never heard of.
I'm close to encourage my children not to get into the IT industry...
I find this attitude kind of depressing. When I was in CS undergrad I thought about going into security because it seemed like this thing where you needed a bunch of systems background. To understand some exploits e.g. [0] you'd need hardware-related knowledge like branch prediction and memory hierarchy. Or something like stack smashing you'd need to know the process memory model and maybe some assembly
It seems to me like security is split into two camps: the people who are out there in the wild who find exploits and the "bootcamp" crowd
[0] https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
Much as you hire an electrician, as opposed to an electrical engineer, to wire your house, or a carpenter, rather than a mechanical / structural engineer, to build your house, I do think we should be finding ways to separate "programmer" from "computer scientist". These are both completely legitimate roles, and deserve to be paid according to their value produced - they're both quite high! But the fact that I need a deep understanding of data structures, operating systems, computer architecture, or other college-level concepts to write software feels like a shortcoming. If CS researchers can set standards for software, rather than _write the software itself_, we can more easily create on ramps and shallow ends for people to use.
Low code tools and LLMs are great steps in this regard, but I feel that they're still stigmatized from the enablement perspective.
Note that the effect goes both ways. Companies started offering ridiculous pay package to less-than-qualified people, ... because the others were doing it.
Trend following is a real nasty human aspect, social media platforms know that too well.
It's so much easier to follow what others are doing than buck the trend and have to justify yourself at every corner decision. Remember the old saying "no one ever got fired for picking Oracle". Well today you'll hear me say "no one ever got fired for picking Salesforce".
Today's industry is plagued by a swath of people coming from all industries into the IT industry, because theirs is shrinking, and because money keeps flowing in this one; pure and simple.
No one really knows what the heck we're doing anymore, and everyone is risk adverse, flows down like the river; because it's impossible to justify yourself in large businesses for bucking the trend.
You'll do better if you can somehow buck the trend at the pivotal points, and read between the lines, but I think we're too far gone past the line of reason these days that it would make a difference.