3 ms·

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.

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.
    - IncRnd 5y ago
      On the contrary, I have found security to be very well defined. Do you have an example for any of those statements labelled 1-3?
  - b3morales 5y ago
    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'".
- aprdm 5y ago
  Does that help with an exec of an arbitrary string from an input? Or a database open to the internet? Or OS level security issues?
  - geoduck14 5y ago
    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.
ehnto 5y ago
> 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.
- lmilcin 5y ago
  > 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.

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.
  - IncRnd 5y ago
    On the contrary, I have found security to be very well defined. Do you have an example for any of those statements labelled 1-3?
- b3morales 5y ago
  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'".
aprdm 5y ago
Does that help with an exec of an arbitrary string from an input? Or a database open to the internet? Or OS level security issues?
- geoduck14 5y ago
  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.

ehnto 5y ago

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

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