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.
DevOps / Security

Security Insights into Infrastructure-as-Code

Organizations taking advantage of automated security testing for their IaC definitions are finding and fixing misconfigurations faster.
Apr 29th, 2021 12:00pm by
Featued image for: Security Insights into Infrastructure-as-Code
Feature image via Pixabay.

Jim Armstrong
Jim is Product Marketing Senior Director, Container and IaC Security, at Snyk. He's taking what he learned at Docker, VMware and McAfee, and helping companies securely build applications using open source, containers and IaC at Snyk.

Cloud native applications are more than just the code developers create: Today’s applications include Infrastructure-as-Code (IaC) that dictates how applications are set up on cloud infrastructure and how containerized applications will run on Kubernetes. The use of IaC allows for faster, repeatable deployments; but its use also increases the burden on developers to secure not only their code and containers but also their infrastructure and deployment configurations.

Our own research (conducted through Virtual Intelligence Briefing) shows that while organizations have not agreed on one “right” way to use IaC, those taking advantage of automated security testing for their IaC definitions are finding and fixing misconfigurations faster than their peers. These high performers are finding and fixing issues in their IaC definitions within a single day twice as often as those who are not using automated testing. Conversely, when asked how often it took more than a week to detect misconfigurations, the group without automation indicated 60% of their incidents fell into this worst-case scenario; versus only 30% for the fully automated cohort. Despite these differences and the risk that comes with running with insecure configurations, many organizations are likely to fall into the lower-performing group, as only 7% of respondents state they’ve implemented IaC to the best of current industry capabilities; whereas 63% say they’re just beginning to explore the technologies.

The benefits to speed and reliability when everything is in code and automated can be immense. But our research shows that the teams responsible for dealing with the security of IaC is another question — and it’s still up in the air. The survey shows that this is an area of shared responsibility today, with responses almost evenly divided amongst developer/DevOps, security and infrastructure. In the future, respondents indicated that developers and DevOps will be increasingly responsible; but that developers will need further help to understand infrastructure and configuration issues, so they are able to secure this new layer in their application stack.

Backseat Driver

Currently, modern applications deploy automatically on infrastructure created and configured via code. As a result, security often takes a back seat to a speedy deployment — meaning configuration issues are not uncovered until after these applications have been deployed. As Gartner states, “By 2025, 70% of attacks against containers will be from known vulnerabilities and misconfigurations that could have been remediated.”

Yet, this does not necessarily mean speed is inherently risky when it comes to IaC. In fact, the automated testing and release gates that are in place for other forms of code can be used with IaC and help make security best practices part of the development and release process. The highest performers — those who are both finding and fixing configuration issues fastest — are already doing exactly that.

However, this type of automated testing is still nascent when it comes to security testing. Nearly two-thirds (60%) of organizations say their current workflow for IaC and configuration code goes through continuous integration (CI) testing, but security checks are not always part of those tests. Only 32% include security checks in their pipelines. In fact, most security issues are still being discovered after deployment — through pen testing, audits, and investigating security incidents. For those who are only using these post-deployment checks, it takes a week or more to discover a security issue in half the cases and over a day to fix those issues in nearly 2/3 of the cases. All in all, that’s potentially nine days of running with a security vulnerability versus less than one day for the highest performers.

For those who said their IaC and configuration code goes through CI testing, the biggest barrier to integrating security checks is a lack of standardized best practices on what to check — with each of their separate teams making their own decision about what to test. When you couple that with the 41% who said that their barrier was unclear benchmarks for security, the shortest path to improved IaC security can be paved with better tools that offer clearer guidance; while still providing teams with the freedom to determine what’s most important for their needs.

Avoid Code Confusion 

Finding the issue is just one piece of the puzzle — once an issue is discovered, somebody has to fix it. When faced with a choice, 52% of respondents claim they usually remediate a security issue by directly tweaking the infrastructure, instead of addressing it by modifying the IaC source code. This opens up the possibility for long-term issues, because the infrastructure and the codified definitions used to create it will start to drift; either that, or the modified infrastructure will be reset to its misconfigured state on the next deployment. For those who choose this manual remediation path, their reasoning is split between a lack of standardization, knowledge and communication, along with a desire to speed up the fixes as much as possible.

One of the barriers to shifting IaC security left was that teams have struggled to standardize practices across their organization, leaving each team to audit IaC as they see fit. In addition to the obvious security issues this presents, it speaks to a larger disconnect on responsibility.

It seems there is no current consensus on who is responsible for the security within IaC. Developers and DevOps roles have a slightly bigger role than other individual teams and a good number say it’s a shared responsibility, potentially fitting the newer DevSecOps models. When asked which team should be responsible for IaC security, if it is not a shared responsibility, the answers shifted heavily to the developers/DevOps groups. So, what’s stopping these security responsibilities from shifting further left? Mostly, it’s confidence in the broader organization’s ability to readily spot and fix issues in the code.

A clear and scalable solution to IaC security challenges is to invest in the tools and training needed to drive up confidence and help with bandwidth for these teams, allowing them to deploy code quickly and securely. In the same “Magic Quadrant” report cited above, Gartner also sees the potential for these automated tools and predicts that, by 2025, organizations will speed up their remediation of coding vulnerabilities by 30% with code suggestions applied from automated solutions; reducing time spent fixing bugs by 50%.

To learn more about IaC, security, and other cloud native technologies, consider coming to KubeCon+CloudNativeCon Europe 2021 – Virtual, May 4-7.

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