Golang was the first programming language to support fuzzing as a first-class experience in version 1.18. This made it really easy for developers to write fuzz tests. Golang 1.14 introduced native compiler instrumentation for libFuzzer, which enables the use of libFuzzer to fuzz Go code. libFuzzer is one of the most advanced and widely used fuzzing engines and provides the most effective method for Golang Fuzzing.
We are thrilled to announce that we secured our Series A funding round of $12 Million to fulfill our vision of a world where security is a given, not a hope. The round was led by US-based Tola Capital and introduced experienced business angels such as Thomas Dohmke. We will use the funds to add support for more programming languages, provide further dev tool integrations and grow the team.
For consecutive years, applications have remained the top attack vector for black hats, with supply chain attacks not far behind. At the same time, market research indicates that enterprise security managers and software developers continue to complain that their application security tools are cumbersome. When asked, many developers admit that they don’t run security tests as often as they should, and they push code to production even when they know it has security flaws.
Coverage-guided fuzzers, like Jazzer, maximize the amount of executed code during fuzzing. This has proven to produce interesting findings deep inside the codebase. Only checking validation rules on the first application layer isn’t providing great benefits, whereas verifying logic in and interactions of deeply embedded components is. To extend the amount of covered code, the fuzzer tries to mutate its input in such a way that it passes existing checks and reaches yet unknown code paths.
Application innovation, design, development, quality assurance, and security testing have changed dramatically over the past decade. Engineering teams are leveraging agile development processes, modern cloud platforms, reusable microservices, and extensible APIs, enabling them to shift to more frequent deployments more easily.
Snyk Code separates itself from the majority of static code analysis tools by generating and maintaining rule sets for its users — helping them combat common and newly discovered threats. A recent Hub article described a new Javascript vulnerability called prototype pollution, which allows attackers to modify, or “pollute”, a Javascript object prototype and execute a variety of malicious actions.
Many Static Application Security Testing (SAST) tools struggle with false positives. They often report that a vulnerability is present, while, in reality, it does not exist. This inaccuracy weighs down the engineering team, as they spend productive hours triaging the false alarms. By setting a benchmark of false positives — a limit, above which is unacceptable — you can establish a point of reference or standard against which to measure the efficacy of your SAST tool.
