Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Security / Software Development

The Disconnect Between Developers and Application Security

In a modern development shop, the role of the security professional shouldn’t just be one of just fixing bugs and pointing out security holes. Rather it should be a role of a service provider, unsuring the devteam has tools to produce secure code. This was the message from a talk by Scott Gerlach, co-founder and Chief Security Officer at application security firm StackHawk, at the All The Talks virtual conference put on by Snyk.
Apr 22nd, 2020 11:06am by
Featued image for: The Disconnect Between Developers and Application Security

As a developer, your responsibilities are wide-ranging as it is — just take a look at what some people refer to as the job description for the mythical “full-stack developer” as an example. Often, “security professional” is a role that can make its way onto that list. You are already concerned with producing a high-performing app that meets quality goals and is easy to use. How can you be expected to be a security professional too?

According to Scott Gerlach, co-founder and Chief Security Officer at application security firm StackHawk, you can’t, and shouldn’t. Gerlach offered this as the first of three points for why developers struggle with AppSec, the title of his panel at last week’s All The Talks virtual conference put on by Snyk.

“You never see the accountants do this to an executive when the executive team goes ‘Hey, we need to model a price increase or change the cost structure for one of these products that we have.’ The accountants don’t go ‘Sweet. We’d be happy to help you with that but let’s teach you about the General Ledger first.’ They don’t have to understand to the nth degree how accounting works, how the General Ledger is set up in that organization, all the details of what the accountants are doing,” said Gerlach. “They can just quickly decide. Plug in information, make decisions. We should do more of that as security teams. We should provide the organization, specifically when we’re talking about AppSec, with tools and information so they can make decisions, so they can decide quickly and get on the path of getting that product out into production.”

While security teams may expect developers to care about security, it’s often a topic at the bottom of their list of concerns, and instead of adding security to their list of responsibilities, providing developers with developer native tools can help to bring security into the workflow. Rather than expecting developers to learn the ins and outs of being a security professional, these tools can help guide them to make decisions with security in mind.

Gerlach’s second and third points both refer to a misalignment, both in expectations of roles and in how the different parts of a business interact with the security team. For example, AppSec teams can work really hard to find security issues and take pride in that process, but then simply throw it over the wall to the developers rather than trying to work together to find a solution.

“We approach the end part of that the wrong way. We come back to engineering and go ‘Hey I broke the crap out of your thing, isn’t that awesome?’ and no one thinks that’s awesome. No one thinks that the hard work that they put in needs to be demonized in the way that we tend to do it because we’re so proud of the thing that we did,” said Gerlach. “That’s another one of those bridge-building functions where we can partner with engineering teams to say, ‘Hey, let’s get together and talk about how this attack worked.'”

“For us to say everything that we find should be fixed is just disingenuous. We’re not in the business of fixing, patching, we’re in the business of providing a service to a customer.”

Not only is there often a lack of communication, says Gerlach, but the security team is so far removed from the development lifecycle that the holes they find may harken back to a change made by the development team weeks if not months ago. Part of the solution here, he says, is to work more closely together to make sure the efforts of both developers and the AppSec team are spent on worthwhile endeavors, which brings us to the last point — the misaligned expectation from the AppSec side of things that demands that developers fix all of the things.

“For us to say everything that we find should be fixed is just disingenuous. We’re not in the business of fixing, patching, we’re in the business of providing a service to a customer, and we should be prioritizing heavily the things that are really, really important, and being able to understand in the context of the organization what are those things that are really, really important,” explained Gerlach.

In his closing thoughts, Gerlach offers that security needs to be democratized through an organization, through the use of tools and information, but that the oft-repeated refrain that “security is everyone’s responsibility” is more a cop-out than anything else. He ends on this point, referring back to his original point about accountants not expecting executives to know the ins and outs of accounting to make their decisions.

“That’s just not how it really works. Accounting is not everyone’s job, pieces of accounting are your job — turn in your expense reports — but accounting is the responsibility of the accounting department. Chances are, everyone is not responsible for cleaning the restrooms, janitors are responsible. We’re responsible for picking up our little pieces of trash. Saying security is everyone’s responsibility is probably just way too broad.”

Developers, in the scenario, again care about code quality and performance and efficiency, and if AppSec teams are going to expect them to care about security, they need to provide them with the tools and information to more easily do so in a way that aligns with their abilities and knowledge.

Snyk is a sponsor of The New Stack.

Feature image via Pixabay.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.