8 ms·

81% of developers admit to knowingly releasing vulnerable apps – research

84 points by samizdis 5y ago

FriedrichN 5y ago
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. https://xkcd.com/2030/ https://xkcd.com/2030/
- pflanze 5y ago
  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.
- mcintyre1994 5y ago
  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.
- lmns 5y ago
  >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.
  - FriedrichN 5y ago
    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.
    - lmns 5y ago
      >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.
samizdis 5y ago
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).
- junon 5y ago
  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.
  - lhnz 5y ago
    You'd presumably be fired or PIPed if you often held back releases for security reasons so the liability seems poorly placed.
  - aliasEli 5y ago
    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.
  - matheusmoreira 5y ago
    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.
aliasEli 5y ago
And the remaining 19% simply don't know that they are doing it.
deleted 5y ago
[deleted]
sublimefire 5y ago
"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.
- macksd 5y ago
  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.
Aeolun 5y ago
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.
fulafel 5y ago
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.
lmilcin 5y ago
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.
- geoduck14 5y ago
  > 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
  - lmilcin 5y ago
    > 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?
    - drewcoo 5y ago
      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.
moksly 5y ago
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?
isubasinghe 5y ago
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
dps910 5y ago
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.
ddek 5y ago
Of course. 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.
- traveler01 5y ago
  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?"
nuncanada 5y ago
19% are too ignorant to know it?
tremon 5y ago
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.
rubicks 5y ago
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?
dep_b 5y ago
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.
IncRnd 5y ago
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.

84 points by samizdis 5y ago

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. https://xkcd.com/2030/ https://xkcd.com/2030/

pflanze 5y ago
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.
mcintyre1994 5y ago
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.
lmns 5y ago
>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.
- FriedrichN 5y ago
  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.
  - lmns 5y ago
    >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.

samizdis 5y ago

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

junon 5y ago
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.
- lhnz 5y ago
  You'd presumably be fired or PIPed if you often held back releases for security reasons so the liability seems poorly placed.
- aliasEli 5y ago
  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.
- matheusmoreira 5y ago
  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.

aliasEli 5y ago

And the remaining 19% simply don't know that they are doing it.

deleted 5y ago

[deleted]

sublimefire 5y ago

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

macksd 5y ago
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.

Aeolun 5y ago

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.

fulafel 5y ago

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.

lmilcin 5y ago

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.

geoduck14 5y ago
> 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
- lmilcin 5y ago
  > 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?
  - drewcoo 5y ago
    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.

moksly 5y ago

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?

isubasinghe 5y ago

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

dps910 5y ago

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.

ddek 5y ago

Of course. 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.

traveler01 5y ago
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?"

nuncanada 5y ago

19% are too ignorant to know it?

tremon 5y ago

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.

rubicks 5y ago

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?

dep_b 5y ago

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.

IncRnd 5y ago

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.