I'm in SecEng and was laid off when my company's regional office went under. It's become pretty obvious to me that there's a huge need for security minded engineers, and most applicants companies get for "Application Security Engineer" roles don't have any experience or background as SWEs.

I'm of the opinion that the industry needs to do a few things to help get traction on the problem:

1. Open up career paths that allow SWEs to move from product develop to technical security 2. Have companies better advertise their need for skilled technical security talent 3. Have InfoSec teams perform more cross team exercises. I've never met an engineer who wasn't all for participating in a red/blue team exercise. It's a fantastic way to cross-train and raise awareness.

So few organisations have dedicated security people at the time they need it most! Since we're on HN, it is maybe worth looking at startups, and how few early stage ones build with security in mind at the time. In regulated sectors or ones where reputation is key, it seems a no-brainer to have a security minded joint CTO/CSO to ensure the house is in order from the start. I understand the pressure and focus on an MVP, but equally I've seen first hand the cost of undoing (avoidably) bad engineering and security ignorance that had real financial cost. After MVP is validated and there are paying customers, it's really time to get security right, in my view.

I also see little demand for "real" security engineers. Most security roles I see are pretty non-technical, often doing the whole "let's turn security into a generic risk so we can hand it off to a non-expert". I don't really see how you can lead or drive security when you can't pop your way into a typical business webapp yourself, yet most of the security people I know what to learn these skills (but they're too busy firefighting for me to get time to teach them some of the tricks).

I've seen little demand or appetite for bringing together what seems to me to be a real security engineer - experienced technical developer lead, deep and broad security knowledge across the full stack, and the ability to make strategic business decisions (exec skills). Is this a missed opportunity, as the value of it seems clear to me? Or is the demand really just not there for this?

Good luck. I’ll stick to Incident Response and SIEM software.

I'm interviewing in SF with ~8 years of product engineering experience and ~2 years of AppSec/SecEng experience. I'm looking at 8 companies that are all willing to pay well for folks to do that work. Typically in range of ~180 - 220k base salary from what I've seen so far.

On the topic of meaningful change: You're absolutely correct in that it's easy for folks in security to find themselves in places where they identify work that needs to happen without receiving support or authority to make it happen. For aspiring technical security folks, there's a few things you can screen for to avoid companies that will do this to you:

1. Does the company have a formal CSIO (Chief Information Security Officer)? If not, move on. CSIOs represent security risks and needs to your executives and board members. Without that, you won't see security work get on anybody's road maps.

2. Does the company have an established security program? If not, do they have a roadmap for making one?

3. What is the size of the technical security team compared to the larger engineering organization? There's no bad ratio here, but the smaller the ratio is, the more critical it is to automate as much as possible.

4. What training programs exist within the larger engineering organization? Do they cover security awareness? Technical security? How well is this program executed? A good training program is critical to reducing new work created for security teams that are typically overloaded to begin with.

There's probably more you can look for here, but I find these questions to be reasonable filters.

> There is a huge market for security engineers If you have a look on Linkedin for "Application Security Engineer" jobs in London, UK you would find there are not that many, some companies don't even have AppSec Engineers.

> Does the company have an established security program? If not, do they have a roadmap for making one?

For less mature company or company just starting out AppSec could be the force that creates and implements a security roadmap, adopting OWASP SAMM or BSIMM

Furthermore, part of me suspects that the tangible business risk of application security flaws isn't felt until after a breach, when its far too late to change things. Even then, sometimes the cost of a breach does not justify the expense of building a robust secure software development life-cycle.

I've run into many stupid security mistakes, and continue to do so :(. Even though security can be very hard, as an industry we'd be way better off if more understood at least the basics. Those with interest/expertise can then dive in and find the more tricky things. Those without, can at least understand WHY these things are important.

Cross team working is important, but I think it's also important to try and embed security "people" into the day to day development flow on a regular basis. It ought to help the developers through learning by osmosis.

Definitely think companies need to better signal the demand for deep technical skills in security though - too many seem to actual want generic risk management experience but no particular technical knowledge. To my mind, anyone in a security role should really be able to break their way into a typical corporate internal webapp in a few minutes, just out of their own residual talent and ability to show stakeholders the importance of their profession. It's amazing how quickly security gets a seat at the table when they show how they can pop the self service password reset portal with just a web browser (with appropriate permission of course) and are asking whose password to reset to show it works...

And what about that PoC that slowly transitioned to bring a production system?

A large part of the blame lies in the culture of pressure on releasing fast and often.

I wish. On the contrary, in my career I met more people that moved from security to development than the other way around.

In many organizations the priority is on churning out stuff and security comes later.

It is clearly proven by the small percentage of security people VS developers.

As a consequence, developers are paid and praised more. Security people end up fighting an endless uphill battle and sometime seen as "party poopers" by the developers.

To me, that's a fantastic situation as a job seeker. It gives me the luxury of choice. Knowing some companies don't value or support their security teams means that it's something I can screen for ahead of time. If I fail to screen appropriately and end up somewhere that I'm not happy with, I can just start looking again.

The need for App Sec is there as far as I’m concerned the demand is non existent... even though most red teams could make them cry.

These should be as basic as not storing cleartext passwords.

Most newly CS students would know better then to do this or at least would know they have to properly look this up.

It's sometimes hard to believe major stupid things like this are done accidentally. (But I know very well how they happen accidentally, it starts with some bug somewhere with non-us-ASCII/to long and similar, then it's constrained "temporary" and put on a must fix list but that list never gets any priority ever, things like this are sadly supper common. As long as companies don't get legally hold responsible for negligence this won't ever go away.)

But the password complexity, rate limiting and other security measurements are there for a reason, and whoever cannot learn from history are doomed to repeat it.

You would think that "not storing cleartext passwords" is a universal given today, but the corporate structure controlling software design today actively suppress anything that isn't a feature. It silos security responsibility to the point where nobody was probably in charge of making sure there was a coherent password policy, that it conformed to any type of standard, or that it was enforced in production against their multiple running systems.

This is every company today.

One thing that causes them to be prioritized where I work is that if they come up during a yearly review, you can't ship your app. Overriding that "stop-ship" order requires C-level approval. Because without a specific exploit, it might be hard to convince a PM to move those up in the backlog.

Sorry, calling BS on this one. You’re calling out an entire group when, like most things, it’s a subset of the broader group. Good PMs understand that a complete product is not just new fancy features but a combination of Features, tech debt work, security and more. At the end of the day if our customers aren’t secure, we’re in trouble.

I’ve been on both teams. Once watching a PM stand n the midst of my engineering team proclaiming “I don’t give an F about your technical debt, when will my features be done?” And now I lead a product management team. Great companies have Product and Engineering trusting each other and working together. They may disagree from time to time, but they deliver together and work together to balance what gets done.

Nearly every single project I've worked on directly or indirectly has had problems (involving security or otherwise) that could have been fixed by a more patient management.

The best thing to learn as an engineer at any level: "rushing makes messes."

Normally, you can pick one. If you are exceptionally lucky, 2. No project is ever all 3 at once, if anyone thinks so for a given project that is a sure sign of either delusion or inadequate ability to judge (after all, good is very subjective).

I have more then one time stumbled about some "wtf is this" thing in libraries which seem to be very good/well maintained/etc.

Things included:

- Setting socket options which are both unnecessary and cause bugs (like non blocking flag on a socket which is used as if in blocking mode without having non-blocking support in that library).

- Not properly clearing secrets while advertising to do so. (I.e. writing zeros without using volatile write or similar, not supper will known but authors of hashing libs can be expected to know better).

- Less obvious Memory leaks.

- Major logic flaws in the application logic which should easily have been cough by tests, except that the tests didn't really test anything. (Through ironically not security flaws.)

- Libraries pretending to support X but only correctly support that common special limited usage of X while having code for full X support but all buggy and 100% unusable outside of the common special case.

- EDIT: Fundamental design flaws in supposedly state of the art, supper fast, supper reliable web framework which makes it not so fast and not so reliable in many real work use-cases under load.

- etc.

It's sometimes really sad.

I'm not sure what the solution is but it probably involves companies getting more active in the development of all the stuff they depend on especially when its not some mega project like linux or postgres.

110% recommended.

I'm in finance, working on back-end systems used by banks. :-D

>My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain.

Jop, that nails it. Software engineers are treated sometimes like children, sometimes like being crackbrained even, but almost never as the highly educated experts they are (or should be, if there wouldn't be so much botchers around also, which for sure causes to some degree the mentioned problem).

Engineering decisions can often be overridden by management no matter what. The result are the usual "catastrophes" repeating over and over everywhere. But as long as this "catastrophes" (like breaches with exfiltration of user data) "require" mostly only a "pardon blog-post" from some executive but don't have any really hurting (financial!) consequences this won't change I guess. If there are costs the insurance will cover them usually. And you need to have and pay the insurance anyway, so why care further? Product management doesn't optimize for security. They optimize costs.

Which as such is not wrong or so! If the incentives would be set by the market provider (the state) correctly the same mechanics could easily lead to improved security. I know many don't like to hear this but imho this industry needs stronger regulation. Without regulation nothing will change as on a free marked the "cheapest" product wins. And it will be (or is, as we can currently see) "cheap" in any dimension. "Worse is better" is a direct result of the fact that the "cheapest stuff" prevail in the long run.

>My recommendation; use the least amount of software you can get by with, and assume it's compromised.

Quite depressed recommendation and fatalistic viewpoint. But to be honest, after so many years in software this could have been my words. And as I see it: Without true political will this conclusion won't change on it's own.

I would be much more worried about security if the developers had access to the production environment than if they didn't.

So far, so good.

The issue was that the “sysadmins” knew almost nothing about how anything worked, so the procedure was that the devs would give them commands to type and they would just type them in to a terminal.

Of course, if anything went wrong, or was ambiguous, the dev would need to check on it, and would end up standing next to the “sysadmin”’s desk and just telling them which characters to type. I once had to explain what a pipe character was...

Anyway, the end result was that all of the devs had prod access, they just had a very slow interface to it.

They already have access to staging and preprod what they do is basically coming to me and saying 'it did run well on their macos machine'

There are outliers, some few good people and some random people having no idea what they are doing.

IMHO there should be random quiz/task/test each day you login. Something obvious but not trivial at the same time related with domain of the system. So you would get 24h access if you pass, get denied for 3 hours if fail. 3 questions in each session...

At least people might learn something out of requirement...

They also had a person who could see if the dev was stalking an ex-girlfriend or pilfering bank account info. Sounds perfect.

PHB: "They need access to all the systems."

Me: "Well, um, what if one of them got disgruntled and just tossed some malicious JS in one of your many, many front end servers? Given the procedures here, it would be unlikely anyone would stumble across it, but they'd get a good amount of hits before the browsers block the entire site and traffic precipitously drops."

PHB: "Nobody would ever actually do that. Besides: we have to give them access. (looks at me as if he's explaining something to a five year old) We're a devops shop..."

There are still vectors for bad actors of course, but the idea is to firewall those who write the code from those who run it.

It can be pretty hard if your organization was not organized with this in mind in the first place.

It devolves into a bunch of managers saying no ops person can have any write access to git at all and no dev person can have any read access to prod, let alone deploy code, thus throwing up a wall to have stuff thrown over.

Separation of duties is the worst, stupidest, clumsiest control ever but all the auditors and management types love it because it doesn't require them to think.

IT controls are far less used as the only control as the Phoenix Project alludes and yet the default state for any auditor is "it's all in Sox scope and everything is an IT control, lock it all down" and unless management has a clue and a care, they just do it.

In the process, they contort the CICD pipeline in horrible ways to say that yes, they have obtained the magical way of separation of duties.

Regarding users caring about security, there's three possibilities:

- Users should care about security but they don't because they're dumb/ignorant.

- Users don't care about security because it's not worth the cost/it doesn't affect them, so they're right in not caring (they have 'nothing to hide').

- Some combination of them.

%s/software/modern &/g

In 2020, you are an "engineer" writing "modern" software.

Don't forget the "updates"!

This is a good observation, it summarizes very well my feeling on what is wrong with the industry today.

In the 90s in many (most?) companies where the product was tech, engineering was in charge of engineering decisions. This meant that feature requests had to pass a sanity filter which would discard or transform ideas which would compromise the soundness of the security, stability, maintainability and other core architectural considerations.

Today, engineering is reduced to fungible user story jira ticket implementors with no decision making power so the more abstract (to PMs) work such as security will get no attention except as a crisis when it generates bad PR.

(source: working as a security-focused eng/architect since the 90s, on both product engineering and infosec sides.)

I do not agree, but I am biased. I'm a former engineer with a security focus that is now a product manager.

I think a more honest take is that security has never been a priority outside of some specialized use cases/industries and that didn't improve as software development moved from something esoteric to something which is business critical in every industry vertical. Even in industry verticals where security is theoretically a priority and a lot of money is spent on security, most of the "security" people don't actually know anything about security and most of the work is box-checking for compliance audits.

You can only do so much and if we're being real security will always compete with other development priorities and the ones which drive revenue always win in any for profit enterprise which creates software as a core competency and the ones which reduce cost always win in any for profit enterprise where software creation is not their core function. Tech is either a product/revenue driver, or it's a cost center, and in both cases security adds additional expense, overhead, and time to release timelines which doesn't pass the PHB smell test.

The other big issue is that security doesn't have strong advocates in most organizations because even the most technical people in most organizations are security illiterate, even in the tech industry vertical. As a SWE at most companies you're a "security genius" if you use a password manager and know how to generate a CSR with OpenSSL or configure Let's Encrypt.

Maybe I'm overly cynical, but I've largely given up on seeing most companies pursue security with the passion and commitment necessary and see policy as the proper way to address these concerns. I applaud things like HITRUST CSF, which is strongly prescriptive and helps drive security in industries where every single company is full of box-checkers who like to buy appliances. I've been fortunate enough to work at companies that take security seriously and appreciate my background and as a product manager I have always considered user security and privacy to be critical and core components of UX in my products. So, I wouldn't blame the PMs, I'd blame the realities of doing business combined with the lack of adequate security literacy across the board in every industry vertical and at every technical role level.

is there financial pain? Is zoom losing money over these security issues? or is paying to fix them going to cost more than the offset in losses they would've had?

Here's our culprit. There IS financial pain but most of it is externalized onto the customers in unseen ways. What is it worth to someone to compromise a specific Zoom meeting? Add up all of the tangible and intangible losses Zoom customers have suffered from data leakage and there is the real cost in the market.

The price Zoom pays to fix another bug, maybe write a blog post, and have a few accounts closed is a small fraction of this full cost to society.

This is probably the strongest argument for regulation such as GDPR.

https://www.psychologytoday.com/us/blog/some-assembly-requir...

So, developers shouldn’t shovel a bunch of third-party advertising SDK’s into their apps?

That’s just crazy talk.

/s