Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Snyk is excited to announce a new, native integration with Atlassian Bitbucket Cloud. This new release improves Snyk’s functionality within Bitbucket Cloud, making installation faster, and easier to implement. Our Bitbucket integration is the first out-of-the-box embedded security experience within the Atlassian UI, enabling users to access high vulnerability counts and rich contextual information right from their native Bitbucket workflow.

Node.js provides a single-threaded JavaScript run-time surface that prevents code from running multiple operations in parallel. If your application typically employs synchronous execution, you may encounter blocks during long-running operations. However, Node.js itself is a multi-threaded application. This is evident when you use one of the standard library’s asynchronous methods to perform I/O operations, such as reading a file or making a network request.

Security and observability data go hand in hand when it comes to application health. If you can put those two sources of data behind a single pane of glass you can make your life a lot easier. By leveraging the different options that the Snyk platform provides, you can send all your application security vulnerabilities found by Snyk directly to your New Relic observability platform. Let’s see how!

Developing and testing a frontend feature can be difficult, especially when the backend it depends on is not ready. This dependency on a backend API often slows down the development process. In scenarios like this, developing a mock API can save you a lot of time by allowing you to develop your feature independent of the backend, and make it easier to test and identify scenarios where your API might fail before it is ready.

In our previous blog breaking down The 5 Fundamentals of Cloud Security, we looked at the value of prevention and secure design. Mapping resource relationships and enforcing security guardrails throughout development helps greatly reduce an available attack surface. But who will enforce these guardrails when your security team is busy with other work? This should be where developers are able to step in. So let’s look at another vital element in cloud security: empowering developers.

Categorizing the challenges and duties of your trusted friend, the site reliability engineer (SRE). From Snyk Ambassador Keith McDuffee, DevSecOps and founder of StackRef.com. “What’s the difference between a DevOps engineer and a site reliability engineer?” It’s a question I hear all the time — and one I’ve heard (and sometimes asked) in job interviews. But is there a correct answer? It all depends on who you ask.

Developer-centric security movements have dominated discussions in software development over recent years. The concepts are clear — integrate security early and find issues faster. But how does an organization measure the success of its developer security program?

First things first, let’s be clear that this is NOT a new Log4Shell or Spring4Shell vulnerability. Although it is a remote code execution issue, the impact is neither as severe nor as easily exploitable as the issue in Log4j from December 2021. Similar to the Log4j issue, the essence of the problem is that you can perform a lookup that can then be misused. However, the Log4shell vulnerability was very easy to exploit — which is not necessarily the case this time.

As a developer, you probably rely on open source every day. Open source code is incredibly beneficial for building and improving products, whether personal or professional. But have you considered going a step further and contributing to open source projects as well? Taking this approach can improve your skills and make a positive impact on the software development community at large. Yet, taking the leap can seem difficult. Where do you start?

When developers need to handle URLs in different forms for different purposes — such as browser history navigation, anchored targets, query parameters, and so on — we often turn to Java. However, its frequent use motivates attackers to exploit its vulnerabilities. This risk of exploitation is why we must implement URL validation in our JavaScript applications.