I had this argument with my bank, who insisted that all payments must be confirmed with their app instead of their card reader code. They presented it as being more secure, which is not true as most people's phones a littered with app that are either easily exploitable or malicious by design. Chances that the average user's phone is compromised is very high.
All people around me that are not involved in tech have so many crap apps on their phone and think I'm weird for not even having Google Play or any other Google service on my phone. It's kinda like that xkcd on voting software, if you work in the business, you know how bad things really are.
I think this Xkcd strip is missing an important point, which is that voting is exposed to a very broad attack vector: probably quite a large percentage of the population would try to corrupt the results if that could go undetected. The risk that electronic voting is exposed to is corruption, not really accidental failure. The other examples in the strip are talking about accidental failure. So while it's true that software quality management is usually (very) bad compared to in engineering disciplines, this is largely because of missing incentives and arguably missing regulation (for worse in this view), which could be changed, but unlike in the engineering cases, it would be a different level of difficulty for regulation to solve the issue, since the devices in question can be exposed to bad actors on pretty much every level. Or with a corrupt government / dictatorship even the regulation agencies themselves could be compromised.
Anyone who wants to put something important in a phone app should be required to give somebody non-technical an Android phone with Facebook installed and take a look at what apps are on the phone after an hour. I'm convinced a big chunk of Facebook's mobile money machine is just advertising blatantly malicious apps and pretending not to know.
>Chances that the average user's phone is compromised is very high.
How do you know? Android and iOS apps are much better sandboxed than desktop applications (which usually aren't really sandboxed at all). I would guess the chance of phones getting compromised is much lower than for the average desktop.
Sandboxes are hardly watertight, especially considering the hardware vulnerabilities that seem to be pouring in in the last years. And the phone have taken over the space for useless applications from the desktop. Most desktops today only have a browser and some office application installed.
But that is besides the point, because a hardware token is almost impervious to attack. One would have to engineer a very specific bit of software or hardware and have physical access to this token. Requiring a phone app to confirm a payment made on your desktop just increases the attack vector.
>Most desktops today only have a browser and some office application installed.
The desktops I see on a daily basis don't have only a browser and office application installed.
I'm not sure which phone or OS you are using, but almost all smartphones have some kind of TPM or TEE nowadays. FWIW, the banking app on my Android phone makes use of that through the KeyChain API.
This, in my experience, is overwhelmingly to blame:
>“If an organisation needs an application to be released to make a specific deadline regarding market opportunity or new features, developers are often caught between hitting that no matter what or potentially delaying the fix of critical or high-risk vulnerabilities.” [said Simon Roe, Product Manager at Outpost24]
And:
>... dev teams are often measured by feature output, and security isn’t usually seen as a feature. “Unless security is viewed as a feature, it will be viewed as a tax,” according to Tim Mackey, Principal Security Strategist at the Synopsys CyRC (Cybersecurity Research Centre).
What's worse, in several jurisdictions (some places in the US included, IIRC), if a company is found to have caused damages based on this sort of "negligence", the developers are legally to blame - not management.
In most jurisdictions I know, the developer would be safe if he could show that he warned management about the security problem. In situation like this always write an e-mail to your manager and keep a copy in a safe place.
The company and its developers should be liable. Developers know it is wrong and yet they do it anyway. The fact management told them to do it doesn't matter.
Real engineers don't sign off on a project if they think the building is going to fall apart. If a company starts ignoring security for the sake of profit, developers should react by literally walking out and refusing to have anything to do with the project. Anything else means they share the blame.
The problem is, what power allows the developer to refuse? If they do, a manager can find someone who won't, and developers who stand by their principles will lose to competition.
A building engineer could probably drop a hint somewhere and have all kinds of inspectors come knocking, but there's no "building code" for software except in very specific cases; it's perfectly legal to develop insecure software otherwise, and to keep that insecurity a secret from users.
> The problem is, what power allows the developer to refuse?
One power we all have is how valuable we are in the jobs market. If you’re a decent engineer in today’s climate, you could get a new software job in days. And it’ll take your company weeks to replace you if they’re lucky, and months to bring your replacement up to speed on what you were working on.
The idea that you’re stuck simply working at the whims of management is a self defeating illusion. It is only as true as you believe it to be.
...but that is an illusion power, because all we'd be doing is shifting from one poorly managed code dump to another, just shifting the faces on the pointy haired bosses. Finding a technology developing organization that is not a shit show of unmanaged personalities and a teetering tower of technical debt is extremely difficult.
I find most employees over estimate their importance. Everyone is replaceable especially a software developer, there are hundreds of just as good developers waiting to take your place if the salary is right. In addition if they fire you on the spot, you are the one that has to deal with that. If the developer does not have a very good emergency fund that further compounds the stress to do as you are told. Not everyone in software makes a US FAANG, SF, NYC salary.
As a remote only 10xer, it take me months to find a new position. Last two search took over six months. I cannot afford to be principled and walk out every time my employer wants to ship buggy code. And we ship bugs pretty much on a weekly basis, because there is no profit in doing things correctly.
> I cannot afford to be principled and walk out every time my employer wants to ship buggy code
And your manager can't afford to fire everyone who pushes back on shipping insecure code. And its not a black and white thing. There's almost always paths which work for everyone. Actively looking for those paths isn't the sign of a bad employee. Its the sign of leadership.
In my experience people who step into that sort of responsibility don't get fired. They get promoted.
> And your manager can't afford to fire everyone who pushes back on shipping insecure code.
I feel like they actually can, since:
- most people want to get paid and to have a job, not get fired over principles
- therefore, they will bend to the whims of management and release whatever they're told to release
- they don't actually have any sort of leverage, as most developers, and are easily replaceable
It is good that your experience is so positive, yet that's not the reality in numerous places.
This is the key reason. Because software products are compiled black boxes, and there is no logical way for a 'software construction building code' or the existence of an 'independent outside-the-company software infrastructure inspector" to exist the industry must develop these roles and must empower them to enforce a structure that the line working developers are not paid to prioritize. It is an extremely tricky mess, of the nature Nobel Prizes in Economics are awarded.
That doesn't seem to be how anything else works. For example, when tech companies colluded to lower wages (anti-"poaching" agreements) I don't believe HR or the executive team was held personally liable. The same holds true for firms who have engaged in racial discrimination in hiring, or covered up risks with a new drug coming to market. Time and time again firms are asked to pay fines in response to executive malfeasance rather then the executives themselves, why is this different?
> Time and time again firms are asked to pay fines in response to executive malfeasance rather then the executives themselves, why is this different?
It's an indication that engineers know in some cases they are releasing broken software, and management may not be aware. Just look at this page and it's article, developers know about this, because they congregate to discuss how they release broken software, know they should do better, yet don't always tell management about faults in the product. A business shield only protects people when they are conducting business.
If I'm taking the lion share of the risk on shipping a product, I'm also collecting the lions share of rewards or I'm not interested in participating. As new vulnerabilities are found every day, I'd expect those rewards to be ongoing, so they would look more like royalties, I'll need to be paid as long as you are using the software. Further I'll need to be able to invalidate that license when I no longer wish to carry the risk.
I think under those conditions most firms would prefer to own the risk themselves.
Those conditions aren't realistic for an employee, since anyone working for someone else who feels that way is bound to be extremely frustrated.
The point that you missed, however, is that an employee should not accept the risk but should transfer the risk by notifying the employer. Otherwise, articles such as this are fodder for putting the blame of exploited vulnerabilities squarely on employees who knew of the risk and, according to some of the comments here, plotted not to tell their employers.
> The fact management told them to do it doesn't matter.
It absolutely does. If you hold any legal power to reject a deployment (like a true engineer), then you can sue the company when they hold it against you, so they won’t.
If you do it in any other situation you are just being difficult.
So, rephrasing your statement, it absolutely doesn't, because software developers don't hold any legal power to reject a deployment (since they aren't true engineers), so they can't sue the company when it's held against them.
If software developers do that they are just being difficult.
Do you have a citation to show that, in any US jurisdiction, a developer can be personally liable for the release of software with a security flaw while management at the same company can't be?
I don't think this is accurate. You can sue the company, you cannot sue the developers. This applies to other companies as well. You can sue McDonalds if you get burned by their coffee, but you cant sue any of the employees that are responsible for selecting to keep the coffee at that temperature.
> you cant sue the worker that made the shake and gave it to you.
I mean let's be real, in the US you definitely could. Pretty much anyone can sue anyone for anything.
But between suing McDonalds, and suing the close-to-minimum-wage-employee working at McDonalds, which group do you think you would be most likely to collect from in the event you won? Not to mention the public perception of suing an individual McDonalds employee.
> I mean let's be real, in the US you definitely could. Pretty much anyone can sue anyone for anything.
No, for this particular example, it would almost certainly not be possible. In the US, employees are shielded from personal liability under the doctrine of respondeat superior.
You can sue them, you just won't win if it goes to trial. But most lawsuits don't end in a courtroom. It's sometimes cheaper to pay off a lawsuit you'd win in court than to go through the process.
> What's worse, in several jurisdictions (some places in the US included, IIRC), if a company is found to have caused damages based on this sort of "negligence", the developers are legally to blame - not management.
[citation needed]
Company employees in the US (including software developers) are shielded from personal liability by their companies, unless that liability was created by breaking the law or gross negligence (with the latter being extremely difficult to prove). The company can fire the developer for being incompetent or negligent, but the company would still be on the hook for any damages.
The same is true when outsourcing development to a third-party development house. The client company may be able to sue the development company, but the individual developers would be shielded from personal liability by whoever they worked for.
The only situation I can think of where a developer would be personally liable for buggy or insecure software is if they signed and sealed source code as a professional engineer (this is practically non-existent), or if they were freelancing and contracting with companies directly. In both cases, they would be eligible--and often required by their clients--to purchase insurance against errors and omissions.
That calls for a big ol' [citation needed]. I've been doing this for over 30 years, and I've never heard of a single instance of this happening. I'm not omniscient, but one would think I'd at least get a whiff of such if it is occurring.
I have seen this changing since the introduction of GDPR in Europe. There is a direct cash incentive to avoid data-leaks. Being mandatory to inform of any data-leak and the possibility of fines makes it more clear that security is a business concern not just a technical one.
"Vulnerable" these days means a lot of things. The question is if you can actually use the vulnerability of a system to gain access or do something meaningful with it.
I'm now looking into one of the Pentest reports. It states that "Header Disclosure" is a low risk vulnerability. If you take it to the extreme then "a lot" of websites are vulnerable. I would question how the survey was carried out and how questions were framed.
This was my thought. A popular open source project will get a lot of wannabes who just want their name on something and file issues from random code analyzers, etc. I've looked at CVEs that don't have a good solution and decided to release because I understood the attack vector and it didn't apply to how we used the library. That's not the same thing.
That said - the problems being discussed here do happen, I just don't know how accurately the headline represents that.
Obviously. I’ve never heard management complain about releasing a vulnerable app as long as they’re not aware of it. But the moment you tell them you’re suddenly in a world of ‘why didn’t we fix this before’, blablabla (never mind the few times you told them before when ‘it isn‘t a priority’), have a few meetings wasting even more time repeating the same things to different people. I don’t think it’s any surprise that a smart developer, even when aware, will claim ignorance.
So anyone have access to the report & can summarize what was the actual phrasing of the question?
Vulnerabilities come in all shapes and sizes, and unless you stick your head in the sand you end up doing "vulnerability management", ie deciding which ones are release blockers and which ones should be treated like other bugs and defects in your app, and what to do about ones that are outside your control in eg platform functionality. Not to mention CVEs in your dependencies that might surface any time.
One statistic missing is in how many of those cases management set an arbitrary release deadline and incentives to release the application no matter its state.
I have never been thanked for delaying a release because of problems I was aware of. Usually it is the opposite, me standing like Gandalf and shouting "You shall not pass!" and management trying to find a way to kill me for it.
There is rarely any cooperation in these matters, it is about who can put more pressure and more foot down and whether I want to risk getting branded as trouble maker.
One contributing factor I don't see people mentioning is that management tends to be absolutely fixated on things that can be easily measured. You can measure timeliness of releases or number of clients or cash flow, but you can't easily measure security, customer or developer satisfaction. With the end result that the things that are important but not easily measurable are getting little to no meritorical discussion.
> but you can't easily measure security, customer or developer satisfaction.
Where I work, we use Chexmark and Whitesource to scan for vulnerabilities. These get routed to grafana. Then to management. Results are available in git within 15 minutes - allowing the merger to wait until the results are available before merging
Developer satisfaction is measured with a quarterly survey that goes to ALL employees
Customer satisfaction is measured with a different survey
> Where I work, we use Chexmark and Whitesource to scan for vulnerabilities.
Umm... that has little to do with security? You may or may not understand, but security is a process and those tools are but small parts of that process.
If security could be guaranteed by tools like the above how are we still hearing about security issues at all?
Security turns out to be an abstract concept. That might still be useful but too many people keep swapping their own definitions in place of others and proceeding as if we're all talking about the same "security."
We commonly hear more about "security snake oil" than snake oils of performance (also slippery to define) or usability (another definitional minefield). Why? I think it's because security fits into the Bermuda Triangle of:
1. loose terminology (that we all argue about)
2. no obvious, casually noticeable effect
3. unknown but real risk
The same as UFOs, psychic phenomena, deities, etc.
And we have an industry built around maintaining that mystique.
I agree, but I think this ties in to the comment above that "management only cares about what it can assign numbers to". A Chexmark report has a punchlist of specific items paired with priorities. This is perfect (leaving aside the issue of the quality of the report) for making the problem concrete to management. And it lets them feel useful by saying stuff like "okay, we don't need to address any of the 'warnings'".
It is just focused on the code in git. It finds things like: Open Source Licensing issues, library versions with KNOWN vulnerabilities, XSS, and SQL injection. It is supposed to work with a variety of languages - but I've only seen it used with a couple.
For an open database to the internet, you will need completely different tools - I speculate network scanning. A bigger problem is running code that DELIBERATELY sends data to an outside source though your proxy.
OS level issues should be managed by a central team that approves the version of OS and EVERYONE installed that EXACT patched OS, and refreshes quickly after patches are released.
> One contributing factor I don't see people mentioning is that management tends to be absolutely fixated on things that can be easily measured. You can measure timeliness of releases or number of clients or cash flow, but you can't easily measure security, customer or developer satisfaction. With the end result that the things that are important but not easily measurable are getting little to no meritorical discussion.
I am 100% on your team here, but I do want to point out that what is important to developers is rarely considered important by the business, more that it's a cost of working with developers. There is no objectively correct "Most important" since there are entirely different priorities and perspectives at play.
At some point, liability notwithstanding, you get left with no choice. If someone wants to sink their company with bad software, regardless of how loudly I tell them that's what they're doing, I really have no choice but to hand them the drill and leave them to it.
> I am 100% on your team here, but I do want to point out that what is important to developers is rarely considered important by the business, more that it's a cost of working with developers.
Well, IMO constant churn of developers who change jobs every 2 years is very adversely impacting quality of the product. When people know and expect they are most likely to be leaving in 2-3 years tops they are not going to stand for what they believe and will be much more amenable to pressure and taking on debt that somebody else is going to be paying.
Now, churn can be easily measured, but its impact on the product or how developer satisfaction contributes to it cannot be easily linked.
IT security isn’t. I work in the public sector and we operate soooo many systems spread out on 876 different departments and around 10.000 employees.
We’re still achieving our NSIS certification. Not because we’re secure, but because all ways to measure IT security come down to documentation, and, we certainly have that part covered.
I guess that somewhere, shops that weren’t already trying to do their best to be as secure as possible with what resources they have, are going to do a GDPR risk analysis and go “hmmmm, maybe we should encrypt those data” or “hmmm, maybe we shouldn’t host our backup locally” or something along those lines. But at the end of the day, you’re still massively understaffed and on insane deadlines and working with tools that simply aren’t designed to be safe.
I think the biggest issue is the illusion that all the documentation and focus will somehow make it safe eventually. It won’t. Not compared to not putting your powergrid on the internet.
We had a big issue with our pools a few years back. For some reason, someone decides to put the pool controls on the internet, so that janitors didn’t have to go work some ledgers or whatever they did before. Of course it was horrible, because pool companies aren’t going to hire the experts or spend the time or money they need to make it as secure as it should be. But the biggest issue I have with it, is why it was done. You may think it was to save money, but the subscription to have the online pool controls were more expensive than having people just to check on them, and it’s not like an organisation with around 150 different buildings aren’t going to have janitors out there anyway.
So there was simply no reason, and nobody really wanted the system, it just came with the pool. Then eventually one of them got hacked and the practice stopped, but do we really need to put these things online?
Yeah my old place didn't give a shit, features were our success criteria.
PMs don't usually care about security really, they also just want to check off boxes. Like my old PM wanted to load test the CDN (AWS) we were using just so that we could check off a DDOS proof box.
I said that load testing AWS was pointless and that we should load test our supporting infrastructure instead and he just dismissed it.
Kinda makes me feel a bit depressed about the state of the industry tbh
I am not surprised by this, of course if there is a deadline to get the app out, they are going to have to release it. But if there are any critical vulnerabilities, they could always be patched with an update.
I've joined a company that uses nuxt with nuxt-auth, which is incapable of securely (i.e. not) storing tokens. This means access tokens are stored by JS in cookies. So I know the app is vulnerable to XSS, but there is no way to fix it because the author of the tool doesn't think it's important.
Honestly, if developers didn't know they were releasing vulnerable apps, I'd be more concerned.
At this point its more about the cost/time management. Stuff will always have errors, its just about "is it worth out time and money to fix this issue?"
Developers don't release apps, product managers do. The media narrative of blaming "developers" is contributing to the core problem by misattributing blame. Of course, even with properly attributed blame, nothing will change, since there is no liability framework.
How is this news? How, in 2021, is the sad state of application security even remotely noteworthy and/or remarkable? These are consumer apps shipped by teams under a perpetual time crunch in an industry that rewards first-movers. Is anyone surprised at the result?
I've seen a few times that people released really awfully engineered applications that leaked information left and right and relied on client-side filtering to hide sensitive data.
It usually takes somebody with a bit of seniority to push these issues to the front, as the management usually only can see visible problems.
Every developer I know has at one time or another released a vulnerable app. There is always the intention to go back and fix it later, but I have never seen that happen.
60 comments
[ 3.6 ms ] story [ 142 ms ] threadAll people around me that are not involved in tech have so many crap apps on their phone and think I'm weird for not even having Google Play or any other Google service on my phone. It's kinda like that xkcd on voting software, if you work in the business, you know how bad things really are.
https://xkcd.com/2030/
How do you know? Android and iOS apps are much better sandboxed than desktop applications (which usually aren't really sandboxed at all). I would guess the chance of phones getting compromised is much lower than for the average desktop.
But that is besides the point, because a hardware token is almost impervious to attack. One would have to engineer a very specific bit of software or hardware and have physical access to this token. Requiring a phone app to confirm a payment made on your desktop just increases the attack vector.
The desktops I see on a daily basis don't have only a browser and office application installed.
I'm not sure which phone or OS you are using, but almost all smartphones have some kind of TPM or TEE nowadays. FWIW, the banking app on my Android phone makes use of that through the KeyChain API.
>“If an organisation needs an application to be released to make a specific deadline regarding market opportunity or new features, developers are often caught between hitting that no matter what or potentially delaying the fix of critical or high-risk vulnerabilities.” [said Simon Roe, Product Manager at Outpost24]
And:
>... dev teams are often measured by feature output, and security isn’t usually seen as a feature. “Unless security is viewed as a feature, it will be viewed as a tax,” according to Tim Mackey, Principal Security Strategist at the Synopsys CyRC (Cybersecurity Research Centre).
Real engineers don't sign off on a project if they think the building is going to fall apart. If a company starts ignoring security for the sake of profit, developers should react by literally walking out and refusing to have anything to do with the project. Anything else means they share the blame.
A building engineer could probably drop a hint somewhere and have all kinds of inspectors come knocking, but there's no "building code" for software except in very specific cases; it's perfectly legal to develop insecure software otherwise, and to keep that insecurity a secret from users.
One power we all have is how valuable we are in the jobs market. If you’re a decent engineer in today’s climate, you could get a new software job in days. And it’ll take your company weeks to replace you if they’re lucky, and months to bring your replacement up to speed on what you were working on.
The idea that you’re stuck simply working at the whims of management is a self defeating illusion. It is only as true as you believe it to be.
And your manager can't afford to fire everyone who pushes back on shipping insecure code. And its not a black and white thing. There's almost always paths which work for everyone. Actively looking for those paths isn't the sign of a bad employee. Its the sign of leadership.
In my experience people who step into that sort of responsibility don't get fired. They get promoted.
I feel like they actually can, since:
It is good that your experience is so positive, yet that's not the reality in numerous places.Here's a similar post from today: https://news.ycombinator.com/item?id=27629543
It's an indication that engineers know in some cases they are releasing broken software, and management may not be aware. Just look at this page and it's article, developers know about this, because they congregate to discuss how they release broken software, know they should do better, yet don't always tell management about faults in the product. A business shield only protects people when they are conducting business.
I think under those conditions most firms would prefer to own the risk themselves.
The point that you missed, however, is that an employee should not accept the risk but should transfer the risk by notifying the employer. Otherwise, articles such as this are fodder for putting the blame of exploited vulnerabilities squarely on employees who knew of the risk and, according to some of the comments here, plotted not to tell their employers.
It absolutely does. If you hold any legal power to reject a deployment (like a true engineer), then you can sue the company when they hold it against you, so they won’t.
If you do it in any other situation you are just being difficult.
If software developers do that they are just being difficult.
https://www.caoc.org/?pg=facts
I mean let's be real, in the US you definitely could. Pretty much anyone can sue anyone for anything.
But between suing McDonalds, and suing the close-to-minimum-wage-employee working at McDonalds, which group do you think you would be most likely to collect from in the event you won? Not to mention the public perception of suing an individual McDonalds employee.
No, for this particular example, it would almost certainly not be possible. In the US, employees are shielded from personal liability under the doctrine of respondeat superior.
[citation needed]
Company employees in the US (including software developers) are shielded from personal liability by their companies, unless that liability was created by breaking the law or gross negligence (with the latter being extremely difficult to prove). The company can fire the developer for being incompetent or negligent, but the company would still be on the hook for any damages.
The same is true when outsourcing development to a third-party development house. The client company may be able to sue the development company, but the individual developers would be shielded from personal liability by whoever they worked for.
The only situation I can think of where a developer would be personally liable for buggy or insecure software is if they signed and sealed source code as a professional engineer (this is practically non-existent), or if they were freelancing and contracting with companies directly. In both cases, they would be eligible--and often required by their clients--to purchase insurance against errors and omissions.
I have seen this changing since the introduction of GDPR in Europe. There is a direct cash incentive to avoid data-leaks. Being mandatory to inform of any data-leak and the possibility of fines makes it more clear that security is a business concern not just a technical one.
I'm now looking into one of the Pentest reports. It states that "Header Disclosure" is a low risk vulnerability. If you take it to the extreme then "a lot" of websites are vulnerable. I would question how the survey was carried out and how questions were framed.
That said - the problems being discussed here do happen, I just don't know how accurately the headline represents that.
Vulnerabilities come in all shapes and sizes, and unless you stick your head in the sand you end up doing "vulnerability management", ie deciding which ones are release blockers and which ones should be treated like other bugs and defects in your app, and what to do about ones that are outside your control in eg platform functionality. Not to mention CVEs in your dependencies that might surface any time.
I have never been thanked for delaying a release because of problems I was aware of. Usually it is the opposite, me standing like Gandalf and shouting "You shall not pass!" and management trying to find a way to kill me for it.
There is rarely any cooperation in these matters, it is about who can put more pressure and more foot down and whether I want to risk getting branded as trouble maker.
One contributing factor I don't see people mentioning is that management tends to be absolutely fixated on things that can be easily measured. You can measure timeliness of releases or number of clients or cash flow, but you can't easily measure security, customer or developer satisfaction. With the end result that the things that are important but not easily measurable are getting little to no meritorical discussion.
Where I work, we use Chexmark and Whitesource to scan for vulnerabilities. These get routed to grafana. Then to management. Results are available in git within 15 minutes - allowing the merger to wait until the results are available before merging
Developer satisfaction is measured with a quarterly survey that goes to ALL employees
Customer satisfaction is measured with a different survey
Umm... that has little to do with security? You may or may not understand, but security is a process and those tools are but small parts of that process.
If security could be guaranteed by tools like the above how are we still hearing about security issues at all?
We commonly hear more about "security snake oil" than snake oils of performance (also slippery to define) or usability (another definitional minefield). Why? I think it's because security fits into the Bermuda Triangle of:
1. loose terminology (that we all argue about)
2. no obvious, casually noticeable effect
3. unknown but real risk
The same as UFOs, psychic phenomena, deities, etc.
And we have an industry built around maintaining that mystique.
For an open database to the internet, you will need completely different tools - I speculate network scanning. A bigger problem is running code that DELIBERATELY sends data to an outside source though your proxy.
OS level issues should be managed by a central team that approves the version of OS and EVERYONE installed that EXACT patched OS, and refreshes quickly after patches are released.
I am 100% on your team here, but I do want to point out that what is important to developers is rarely considered important by the business, more that it's a cost of working with developers. There is no objectively correct "Most important" since there are entirely different priorities and perspectives at play.
At some point, liability notwithstanding, you get left with no choice. If someone wants to sink their company with bad software, regardless of how loudly I tell them that's what they're doing, I really have no choice but to hand them the drill and leave them to it.
Well, IMO constant churn of developers who change jobs every 2 years is very adversely impacting quality of the product. When people know and expect they are most likely to be leaving in 2-3 years tops they are not going to stand for what they believe and will be much more amenable to pressure and taking on debt that somebody else is going to be paying.
Now, churn can be easily measured, but its impact on the product or how developer satisfaction contributes to it cannot be easily linked.
We’re still achieving our NSIS certification. Not because we’re secure, but because all ways to measure IT security come down to documentation, and, we certainly have that part covered.
I guess that somewhere, shops that weren’t already trying to do their best to be as secure as possible with what resources they have, are going to do a GDPR risk analysis and go “hmmmm, maybe we should encrypt those data” or “hmmm, maybe we shouldn’t host our backup locally” or something along those lines. But at the end of the day, you’re still massively understaffed and on insane deadlines and working with tools that simply aren’t designed to be safe.
I think the biggest issue is the illusion that all the documentation and focus will somehow make it safe eventually. It won’t. Not compared to not putting your powergrid on the internet.
We had a big issue with our pools a few years back. For some reason, someone decides to put the pool controls on the internet, so that janitors didn’t have to go work some ledgers or whatever they did before. Of course it was horrible, because pool companies aren’t going to hire the experts or spend the time or money they need to make it as secure as it should be. But the biggest issue I have with it, is why it was done. You may think it was to save money, but the subscription to have the online pool controls were more expensive than having people just to check on them, and it’s not like an organisation with around 150 different buildings aren’t going to have janitors out there anyway.
So there was simply no reason, and nobody really wanted the system, it just came with the pool. Then eventually one of them got hacked and the practice stopped, but do we really need to put these things online?
PMs don't usually care about security really, they also just want to check off boxes. Like my old PM wanted to load test the CDN (AWS) we were using just so that we could check off a DDOS proof box.
I said that load testing AWS was pointless and that we should load test our supporting infrastructure instead and he just dismissed it.
Kinda makes me feel a bit depressed about the state of the industry tbh
I've joined a company that uses nuxt with nuxt-auth, which is incapable of securely (i.e. not) storing tokens. This means access tokens are stored by JS in cookies. So I know the app is vulnerable to XSS, but there is no way to fix it because the author of the tool doesn't think it's important.
Honestly, if developers didn't know they were releasing vulnerable apps, I'd be more concerned.
It usually takes somebody with a bit of seniority to push these issues to the front, as the management usually only can see visible problems.