The report claims that only 11% of open-source projects are actually actively maintained. 

Despite these flaws, Sonatype still says that 96% of vulnerabilities are avoidable. There were 2.1 billion downloads of open-source software that had known vulnerabilities for which there was a newer version with the issue fixed. 

“A lot of maintainers are very diligent – Big Tech companies go out of their way to hire talented people to maintain libraries they rely on,” said Brian Fox, CTO at Sonatype. “Our industry needs to direct its efforts towards the right place. The fact that there’s been a fix for almost all downloads of components with a known vulnerability tells us an immediate focus should be supporting developers on becoming better decision-makers, and giving them access to the right tools. The goal is to help developers be more intentional about downloading open source software from projects with the most maintainers and the healthiest ecosystem of contributors. This will not only create safer software, but also recoup nearly two weeks of wasted developer time each year.”

The number of supply chain attacks continues to increase year-over-year. In 2023, there were twice as many attacks as the combined number from 2019-2022. This equates to 245,032 malicious packages, with one in eight open source downloads containing a known vulnerability. 

Sonatype also said they found a disconnect between how secure companies think they are versus the reality. 67% say they are confident they don’t have code from vulnerable libraries in their systems, but 10% have suffered a security breach due to vulnerabile components this year.

And finally, the company found that 39% of companies find a vulnerability within one to seven days, 29% take over a week, and 28% take less than one day.  

The post Sonatype shines light on current state of supply chain security in latest report appeared first on SD Times.

New Sonatype product features include:

• Additional Cloud Delivery Options: Streamline the procurement process with Sonatype Lifecycle and Sonatype Repository Firewall on AWS Marketplace. Sonatype Repository Firewall is also now available as a convenient SaaS solution, making onboarding easier than ever before.
• Streamlined User Experience: Easily control open source risk with improved navigation, compatibility enhancements, and extended inclusion of wildcard characters in Sonatype Lifecycle. Sonatype Repository Firewall enhancements feature cleaner views and improved discoverability of specific repositories and violations to simplify automated policy enforcement.
• Simplified Onboarding and Administration: Effectively manage the onboarding process in Sonatype Nexus Repository with enhanced privilege administration and Quick Action to expedite common tasks, such as blob storage mapping and connecting new proxy repositories. With the new Sonatype Repository Firewall onboarding experience, AI-enhanced malware protection and vulnerability scanning for Nexus Repository can be turned on in minutes.
• Improved Search Capabilities: Effortlessly connect new proxy repositories with streamlined connectivity in Sonatype Nexus Repository. Additional improvements include search capabilities for dates and times, along with faster component repository selection, contributing to a more intuitive and user-friendly experience.
• Deeper Customization Capabilities: Sonatype Lifecycle users now have even more power to tailor vulnerability details for their environment, organization, and deployments, including the ability to customize CVSS Vector Strings, Severity, and CWE-IDs.
• Boosted Observed License Coverage: Using the latest machine learning (ML) models, Sonatype Lifecycle has supercharged observed license detection with its Advanced Legal Pack, helping enterprises meet OSS license compliance obligations without sacrificing development velocity.
• Enhanced Release Integrity Detection: Block malicious open source at the door with improved AI and ML-driven malicious package detection in Sonatype Repository Firewall.

“In today’s rapidly evolving digital landscape, organizations are in a continuous innovation cycle to retain their competitive edge, making speed paramount to success. That means software developers not only serve as a business-critical function to drive innovation and revenue, but also play a crucial role in fortifying ecosystems against relentless cyber threats,” said Mitchell Johnson, Chief Product Development Officer at Sonatype. “With this enhanced product functionality, Sonatype is enabling developers and engineering teams to accelerate productivity without sacrificing security. Teams can identify and mitigate risk earlier, innovate faster, and develop software fearlessly.”

Sonatype’s groundbreaking software supply chain management platform empowers customers to rapidly create, deploy, and maintain innovative software at scale. More than 2,000 organizations, including 70% of the Fortune 100 and 15 million software developers, rely on Sonatype to be ambitious, move fast and do it securely.

“Sonatype is continually recognized for its forward thinking, industry-leading approach to software supply chain security,” said Alex Berry, President at Sonatype. “We’re proud to offer best-in-class, cutting-edge security solutions that exceed the evolving needs of our customers, and are thrilled for what’s to come.”

To learn more about Sonatype’s new product enhancements, visit the Sonatype blog.

ABOUT SONATYPE
Sonatype is the software supply chain management company. Recognized by globally renowned analysts as a leader in the industry, Sonatype enables organizations to innovate faster in a highly competitive market. We allow engineers to develop software fearlessly and focus on building products that power businesses. Sonatype researchers have analyzed more than 120 million open source components – 40x more than its competitors – and the Sonatype platform has automatically blocked over 145,000 malicious components from entering developers’ code. Enabling high-quality, secure software helps organizations meet their business needs and those of their customers and partners. More than 2,000 organizations, including 70% of the Fortune 100 and 15 million software developers, rely on our tools and guidance to be ambitious, move fast and do it securely. To learn more about Sonatype, please visit www.sonatype.com.

The post Sonatype Drives Intelligent Software Security with New Product Enhancements appeared first on SD Times.

Nexus Lifecycle and Nexus Firewall can now be deployed in the cloud, which enables companies to get up and running with these offerings faster, with enterprise-grade security baked in. It eliminates the need to manage infrastructure, while still getting the benefit of being able to protect the supply chain. 

According to Sonatype’s State of the Software Supply Chain report, there has been an average annual increase in supply chain attacks of 742% per year for the past three years. This makes getting a supply chain security solution up and running quickly more important than ever. 

“There has never been a greater need for the ability to detect code quality and implement security at the point of creation. Sonatype is answering that need and more, allowing developers, engineering teams, and enterprises to build software fearlessly in the environment that best works for them,” said Mitchell Johnson, chief product development officer at Sonatype. 

In addition to faster deployments and scalability, companies can save money by avoiding paying for physical space or resources they don’t need. Configurable APIs also make it easy to connect these solutions with your existing tools. 

The post Sonatype’s OSS security offerings can now be deployed in the cloud appeared first on SD Times.

In an SD Times Live! Event titled “Threat Landscapes: An Upstream and Downstream Moving Target,” Theresa Mammarella, developer advocate at Sonatype, explained how companies can stay vigilant and be prepared for these malicious attacks. 

“It becomes harder and harder as there’s more and more layers of software building on top of each other to actually know what’s in these applications,” she explained. For example, you could be using Kubernetes, and that project could be pulling in code from thousands of other projects that you might not even know about. Mammarella labels these as “transitive dependencies.” 

According to her, there are three main attack points in a software supply chain. The first is upstream, which involves downloading open-source or third-party componentss. The NPM attack is one example of an upstream attack.

The second is midstream, where an attack takes place somewhere in the development life cycle. An example of this is the Log4j exploit.

And third is downstream, which is when an attack takes place within the deployed application. 

“So upstream, midstream, and downstream, this all makes me think of a river,” Mammarella explained. “And there is a good reason for that. Niagara Falls, think about it, the water that is upstream moves faster and spreads more widely than does the water in the midstream or the downstream of a river or waterfall. And those upstream attacks can have the most impact on software supply chains.”

According to Mammarella, of the millions of repositories on GitHub, many of those projects get distributed to hundreds of thousands or even millions of companies. The most popular ones often get targeted the most because they have the most number of downloads and thus are more attractive to attackers.

To learn more about how to protect your software supply chain, watch the recording of the event. 

The post Threat landscapes: An upstream and downstream moving target appeared first on SD Times.

A large part of this is due to lack of security automation, explained Ax Sharma, senior security researcher, and advocate at Sonatype, in a webinar called “The Impact of Zero-Day Attacks on SSC Management.” 

The company also found that when it came to the big breaches such as Log4Shell in December 2021 and Spring4Shell that allowed attackers to remotely execute malicious code, companies that didn’t automate their supply management and weren’t paying attention to vulnerabilities were especially vulnerable. 

The Sonatype Log4j Resource Center dashboard also shows that downloads of Log4Shell have dropped from 50% at the time of the vulnerability disclosure to 33%, but that’s still a lot, according to Sharma. 

“At the time, people were very concerned if they are vulnerable to the Log4Shell vulnerability,” Sharma said. “If you’re using a few components, it could be a component within a component within a component that contains this library, and you just don’t know how it’s being used in your environment. So I think this is where automation wins because you need to find the vulnerable class and the vulnerable code and exactly how it’s being used.”

Since organizations can’t expect their security teams to go through thousands of lines of code and files per day with a manual approach, they can utilize free scanners from companies like SISA, Google, and Microsoft to see if they’re vulnerable to Log4j and can also use essential perimeter security controls. 

“Even if you were impacted by Log4j and you had strong incident response tools in place like a good IDS or IPS, maybe suspicious traffic could be flagged by those rules,” Sharma said. 

Another suggestion is to patch vulnerabilities fast by prioritizing CVEs based on how much each one impacts the environment. There were so many Log4Shell CVEs, but not all of them were critical, and this left system admins and management confused and scratching their heads over the holidays deciding what to prioritize.

Getting updates is also sound security advice, Sharma explained, but make sure that the updates are legitimate and safe and don’t break anything. Such was the case with the SolarWinds attack that was caused by updates that contained trojanized dynamic link libraries (DLLs).

To learn more, watch the webinar “The Impact of Zero-Day Attacks on SSC Management,” available on-demand now. 

The post Lack of automation leaves companies vulnerable to attacks like Log4Shell and Spring4Shell appeared first on SD Times.

In late 2021, a vulnerability was detected in Log4j, which is a framework for logging in Java that is used as a dependency in over 7,000 open-source projects. This was just one example of a software supply chain security risk that companies have had to pay attention to in recent years. 

Managing what’s in your software supply chain is not only important for security purposes, but it can also eliminate technical debt and innovation tax, leading to increased productivity and revenue. 

In a recent SD Times Live! event, “Software Supply Chain Hygeine: The Big Picture,” Steve Poole, developer advocate at Sonatype, discussed how to achieve those benefits by investing in software supply chain hygiene. 

“There’s no real rocket science here,” said Poole. “If you’re going to produce better quality software, you’ve got to have a better, more secure pipeline. And you’ve got to be serious about this and you’ve got to start looking at the end to end thing.”

What this means, Poole explained, is developers gaining an understanding of how their application fits in the overall pipeline. For example, if they have an API gateway, then they can use tools that monitor the behavior of those. 

This understanding requires more collaboration from different groups in the organization, rather than only understanding what their individual part does and viewing the rest as black boxes. 

“Once you realize that having a high speed CI/CD system makes you safer, you soon realize that they improve your productivity, because you’ve dealt with all those human parts, right? Once you realize that poor code quality makes you vulnerabl and you start worrying about code quality, and put tools in place for that in all these things, and you improve the communication between your team members, when you finish, what you’ve actually got is a much slicker engine. And it just produces higher quality code faster because you’ve taken out those sort of nasty edges.”

To learn more, catch the replay of “Software Supply Chain Hygiene: The Big Picture,” and join us again on Wednesday, May 18 2022 at 1 PM ET / 10 AM PT for another webinar with Sonatype about software supply chain security: “Impact of Zero-Day Attacks on SSC Management.” 

The post Software supply chain hygiene: The big picture appeared first on SD Times.

Having all of these connected devices that don’t live under one network expands the attack surface that security teams need to worry about. This is especially true when you’re talking about remote or hybrid work, explained Ev Kontsevoy, CEO of Teleport, which is a company that provides tooling that enables users to remotely access computing resources. 

Kontsevoy explained the perimeters in internet and application security terms are breaking apart completely, in two major ways. One is the type of perimeter that exists around your data center, where your equipment like servers or computers actually live, and the second type of perimeter is the office itself, which is where all the employees who work there sit and need access to data and applications. This is where technology like firewalls come in, Kontsevoy explained.  

“That’s the traditional approach that now makes no sense whatsoever,” said Kontsevoy. “And the reason why it doesn’t make sense is because computers themselves are not in the same data center anymore. So we’re now doing computing globally.”

RELATED CONTENT:
How these companies help organizations with DevSecOps
A guide to DevSecOps tools

Kontsevoy used the example of Tesla. What is Tesla’s perimeter? Tesla deploys code to each of its charging stations, data centers, and cars. “Tesla deploys into planet Earth … Most organizations, they’re moving into the same direction. So computing itself is now becoming more and more global. So the notion of a perimeter makes no sense in a data center,” said Kontsevoy. 

Conversely, no one is sitting in an office anymore. “Now, we have engineers, contractors, auditors, and interns, all sitting in different parts of the world, using computers that might not necessarily be company computers,” said Kontsevoy. “They can borrow an iPad from their partner to do a production deployment, for example. For that reason, traditional security and access solutions are just no longer applicable.”

According to Jeff Williams, chief technology officer at application security company Contrast Security, this idea of a perimeter had been dismantled long before COVID. In fact, he says people had a misguided sense of security in a perimeter that didn’t actually exist. 

“Once any one computer inside the perimeter gets compromised then there’s what’s called the soft, chewy center where there’s nothing inside to prevent an attacker from moving around and doing whatever they want,” said Williams. “So the best strategy for a long time — since way before COVID — has been to really sort of consider your internal infrastructure as the same as your external infrastructure and lock it down.”

According to Williams, development machines are traditionally not very locked down and developers generally have the privileges to download any tools they need. 

“They’re running, honestly, thousands of pieces of software that come from anywhere on their machines, all the libraries that they use run locally, all the tools that they use run locally, typically with privilege, and any of that code could potentially compromise the security of that company’s applications. So it’s something that DevSecOps programs really need to focus on,” said Williams.”

Williams also believes the current speed at which DevOps teams want to move isn’t really compatible with the old way of doing security. For example, scanning tools, which have been around for over a decade, aren’t very accurate, don’t run very quickly, and don’t really work well with modern applications because they don’t work on things like APIs or serverless. 

In order to move fast, companies will need to abandon these older tools and move on to the new ones, if they haven’t already. Interactive Application Security Testing (IAST) and Runtime Application Self Protection (RASP) are two newer technologies that work fast and are part of developers’ normal pipelines. 

“As the developers write their code, they can get instant accurate feedback on what they’re writing,” said Williams. “And that allows them to make those fixes very quickly and inexpensively, so that the software that comes at the end of the pipeline is secure, even if they’re moving at very high speed.”

Lack of automation and integration becomes even more problematic 

The act of actually working remotely doesn’t seem to make it harder for DevSecOps teams to work together. According to software supply chain security company Sonatype’s CTO Brian Fox, certainly, companies need to get tools that will make collaboration easier in a distributed setting, but he believes the core of DevSecOps remains the same.

However, when a company goes remote, one of the first things that happens is the touch points that could cover up a lack of automation no longer exist, Sandy Carielli, principal analyst at Forrester explained.

“You don’t have those situations where you can walk to the next cube over and get a sign off from someone on the security or legal team … So as you started to have more people forced to go remote, the importance of having better integration of security tools into the CI/CD pipeline had better automation and better handoffs so that everything was integrated, and you could have sign offs in tool stage gates, all of that becomes a lot more important,” she said.

According to Carielli, implementing tools that enable automation and integration between different security tools is a high priority. 

Asynchronous DevSecOps

A new thing that has sprung up for remote teams is the notion of asynchronous communication, where individuals are not necessarily communicating in real time with their coworkers. They might send someone a message and then have to wait a little bit for a response. 

DevSecOps is also becoming a bit asynchronous, according to Guy Eisenkot, VP of product and co-founder of Bridgecrew by Prisma Cloud, which provides security automation. 

“I think three years ago, we may have not even had the tooling, but now we can just ping each other on Slack,” said Eisenkot. You know, ask the developer, ‘Hey, did you intentionally commit this password? Or this access key into your code repository? Was that intentional?’ And the response can come in in a conversational manner and come in at any hour of the day. So I think the position for security has changed pretty drastically with how well connected we are and how we’re much better at async communication.”

Now there’s a much stronger emphasis on when you should be available and when you’re expected to be responsive. 

Remote-first mindset tooling helps developers think about security

The tooling that companies have had to invest in to stay successful when remote has also had benefits for security, according to Eisenkot.

Employers and managers have been much more deliberate about the type of tooling they put on developers’ machines, allowing for more control of the linting and securing tooling they have locally, Eisenkot explained. 

“Not only are we kind of protecting them with remote endpoint detection, but we can also now force them to use or enforce the usage of security tooling directly on the employees endpoint, which is something that I think was expedited by the fact that we’re no longer in the office and everybody had to now apply to the same type of corporate policy on their on their work computers,” said Eisenkot.

Embedding security into development tooling is now easier than ever

In addition to the fact that remote tooling is making it easier to enforce security, there’s also something to be said about the fact that it’s getting easier and easier to embed controls into the development pipeline.

As an example, Eisenkot explained that both its source control management and shipping pipelines are more accessible than they used to be and are controlled remotely using publicly accessible APIs. 

He believes development organizations should now find it much easier to incorporate things like secret scanning, open source package scanning, image scanning, and code scanning directly into the developer’s initial commit review process. 

“Some of these in the past were just not accessible. So the fact that this tooling was much cheaper, most of it is actually open source, but much more accessible through those public APIs. I think that’s where I would start by scanning either directly on developers’ individual workstations, that would be through extensions and IDs, and then implement stronger and stricter controls on source control management,” said Eisenkot. 

The fact that it’s easier than ever to place security controls on developers’ machines is extra important these days, since supply chain attacks are becoming more and more common. According to Sonatype’s Fox, attackers no longer want to get their malware into a shipped product, they want to get it into part of the development infrastructure. 

“And once you understand that, you can’t look at perimeter defense in terms of application security the same way anymore because it moves all the way left into development,” said Fox. 

Security as coaches to developers rather than ultimate authority

Another interesting thing that’s been happening in DevSecOps is that the role of security is changing. In the past security was more like a bottleneck, something that stood in the way of developers writing and pushing out code fast, but now they’re more like coaches that are empowering the developers to build code and do security themselves, said Contrast Security’s Williams.

It used to be that the Sec part of DevSecOps was like the central authority, or the judge. If they determined code wasn’t secure, it got sent back to the development team to fix. 

“DevSecOps, when you do it right, is bringing development and security together so that they can have a common goal. They can work and they can sort of agree on what the definition of done is. And then they can work together on achieving that goal together,” said Williams.

When DevSecOps is done wrong, it’s more like trying to fit a square peg into a round hole, Williams said. Companies try to take their existing tools, like scanners that take a long time to run, and put them into their already existing DevOps pipelines, and it just doesn’t work. 

“Usually, it doesn’t produce very good results. It’s trying to take your existing scanners that take a long time to run and don’t have very good results, and just kind of wedge them in or maybe automate them a little bit. But it’s not really DevSecOps; it’s really just trying to shove traditional security into a deficit DevOps pipeline,” said Williams.

According to Williams, there are three key processes that companies need to have in place in order to have a successful DevSecOps organization. First, they need a process around code hygiene to make sure that the code the developers are writing is actually secure. Second, they need a process around the software supply chain in order to make sure that the libraries and frameworks that are being used are secure. Third, they need a process to detect and respond to attacks in production. 

“If development and security can come together on those three processes and say ‘hey, let’s figure out how we can work together on those things. Let’s get some tools that are a little more compatible with the way that we build software,’ that will help get them moving quickly in development,” said Williams. “And then in the production environment get some monitoring, that’s a little more up to date than just something like a WAF, which is a kind of firewall that you have to keep tailoring and tuning all the time.”

Traditional challenges to DevSecOps remain

According to Sonatype’s Fox, the main challenge companies are facing when it comes to DevSecOps is understanding the components in their software. Log4j is a great example of this, since if you look at the download statistics from Maven Central, around 40% of the downloads are still of the vulnerable version. 

“And that can’t be explained,” said Fox. “A lot of times, you can explain why people are not upgrading or doing things because well, the vulnerability doesn’t apply to them. Maybe they have mitigation controls in place, maybe they didn’t know about it otherwise, and so they didn’t know they needed to upgrade. For the most part, none of those things apply to the Log4j situation. And yet, we still see companies continuing to consume the vulnerable versions. The only explanation for that is they don’t even know they’re using it.” 

This proves that many companies are still struggling with the basics of understanding what components are in their software.

According to Fox, automation is important in providing this understanding. 

“You need a set of tools, a platform that can help you precisely understand what’s inside your software and can provide policy controls over that, because what is good in one piece of software might be terrible in another piece of software,” said Fox. “If you think about license implications,  something that’s distributed can trigger copyright clauses and certain types of licenses. Similar things happen with security vulnerabilities. Something run in a bunker doesn’t have the same connectivity as a consumer app, so policy controls to then have an opinion about whether the components that have been discovered are okay in their given context is important. Being able to provide visibility and feedback to the developer so they can make the right choices up front is even more important.”

According to Bridgecrew by Prisma Cloud’s Eisenkot, if you look back on the big supply chain-related security incidents over the last six to eight month, it’s apparent that companies have not properly configured the correct code ownership or code review process in their source control management.

He explained that those two things would make any source code much more secure, even in small development organizations.

Developer education is key

Eisenkot emphasized that developer education and outreach is still one of the most crucial points of DevSecOps, at the end of the day.  

It’s important to implement controls and checkpoints in the tooling, but he also believes the tooling should be thought-provoking in a way that it will empower developers to do out and educate themselves on security best practices. 

“Eventually, lots of tooling can point to a vulnerable package or a potentially exploitable query parameter,” said Eisenkot. “But not every tool will be able to provide actionable advice, whether that’s a documentation page or an automatically generated piece of code that will save the developer the time needed to now learn the basic fundamentals of SQL injection as an example.” 

Executive Order on improving Cybersecurity in the U.S.

Last spring, President Biden signed an executive order related to improving cybersecurity. As part of this order, the government will solicit input from the private sector, academia, and others to “develop new standards, tools, best practices, and other guidelines to enhance software supply chain security,” according to the National Institute of Standards and Technology (NIST). 

These guidelines will include criteria for evaluating software security, criteria for evaluating security practices of developers and software suppliers, and tools and methods for demonstrating that products are following secure practices. 

“They’ve demanded that organizations be more transparent,” said Contrast Security’s Williams. “They put out minimum testing guidelines, and NIST is implementing these standards. They’re even investigating the idea of having software labels, so that when you go to your bank, or you buy software from somewhere, you’ll see a label that says, hey, here’s the details about security that you need to know. Kind of like everything else in this world has labels, like Energy Star and your car and your drugs and your Cheerios box has a label and your movies and your records. Everything has labels because they work. They fix economic problems in the market. And that’s going to happen to software over the next few years, which I think is exciting. It’ll make it much better for consumers to know that the software they’re using is trustworthy.”

The post Security perimeter is no more as attack surface continues to expand appeared first on SD Times.

Guy Eisenkot, VP of product and co-founder of Bridgecrew by Prisma Cloud

As hybrid work environments and cloud infrastructure environments become the norm, organizations’ attack surfaces are only getting larger and more complex. With less cohesive visibility into the multitude of tools and frameworks used across software supply chains, it’s hard for organizations to keep up with security risks and best practices. To mitigate those risks brought about by cloud complexity and remote work, many organizations are embracing DevSecOps.

Bridgecrew by Prisma Cloud helps organizations adopt DevSecOps seamlessly through continuous, proactive security measures for every team—from engineering and DevOps to security and compliance.

For engineering, Bridgecrew makes it easier to prevent infrastructure misconfigurations and vulnerabilities from progressing into build pipelines and production environments by surfacing feedback in developer tools. Via command lines and integrated development environments (IDE), Bridgecrew provides fixes as code so developers can adhere to secure coding practices.

RELATED CONTENT:
Security perimeter is no more as attack surface continues to expand
A guide to DevSecOps tools 

For DevOps, Bridgecrew enables speed and agility by automating security guardrails throughout the development lifecycle. Bridgecrew also comes equipped with the tools DevOps need to keep their software supply chain secure—from the individual components to the version control systems (VCS) and continuous integration (CI) pipelines that deliver them. 

Lastly, for security and compliance, Bridgecrew provides unified visibility into the security posture of all cloud resources and real-time notifications and ticketing to enable cross-functional collaboration. These are crucial for DevSecOps to be effective in the hybrid work environment when employees work remotely in varying time zones. 

With Bridgecrew by Prisma Cloud, organizations can bridge the gap between security and engineering regardless of where teams are located around the world.

Jeff Williams, chief technology officer at Contrast Security

Contrast is a platform of products that tries to enable teams to do their own security. So in a remote kind of environment, it’s really important to empower the developers to have the ability to test their software locally, as part of every time they change the code, they’ll get instant results. And our philosophy is sort of, they shouldn’t have to change anything about the way that they build, or test or deploy their code, they should just do their normal process. And the security tooling should be the thing that does the work, and then alerts them if there’s ever a problem. But we don’t want the developers to have to take extra steps. Because what ends up happening is they get frustrated with those extra steps. If there’s false positives, they have to go do extra work for no reason to investigate those things. So we want to just empower them to just deal with the things that actually matter, make those changes themselves and check and clean code. And we want to do that really early in the development process. So that’s the role that Contrast plays — we’re just in the background doing our job. And if anything goes outside the guardrails a little bit, we help steer the developers back on track. Now, the security team can participate. They serve as managing the policy, they watch the metrics, they can go help projects that aren’t doing very well. But by monitoring all of their applications continuously, it gives you a very different viewpoint than if you’re just running tools, running scanners, kind of serially, one by one through your entire application portfolio. And remember, we’re typically working with organizations that have hundreds or thousands, or even ten of thousands of applications, all in development at any given time. So it is really a complex problem to deal with.

Ev Kontsevoy, CEO of Teleport

Hybrid is the new normal. Hybrid work arrangements have put pressure on the corporate network, and employees at different levels of seniority need to be able to connect to corporate infrastructure from anywhere. Additionally, that infrastructure is increasingly complex. A typical customer environment is itself hybrid with Linux and Windows servers, Kubernetes clusters, databases, and internal applications like CICD systems and version control systems like GitLab. In this environment, protecting modern applications requires the consolidation of all aspects of infrastructure access into a platform built for a hybrid world. That platform is the Teleport Access Plane, the easiest, most secure way to access all an organization’s infrastructure. The open-source Teleport Access Plane consolidates the four essential infrastructure access capabilities every security-conscious organization needs: connectivity, authentication, authorization, and audit. By consolidating all aspects of infrastructure access into a single platform, Teleport reduces attack surface area, cuts operational overhead, easily enforces compliance, and improves productivity. The Teleport Access Plane replaces VPNs, shared credentials, and legacy privileged access management technologies, improving security and engineering productivity.

With Teleport, organizations can easily shift to remote work and increase their use of hybrid cloud environments without impacting security or productivity. Teleport enables teams to securely connect to your global infrastructure regardless of network boundaries and provides identity-based access for humans, machines, and services, including fine-grained access controls. It enables teams to achieve unprecedented visibility into infrastructure access and behavior so they can meet and exceed compliance objectives.

The post How these companies help organizations with DevSecOps appeared first on SD Times.

“It is almost the inverse of the industrial revolution in some way,” says Brian Fox, chief technology officer of Sonatype, which specializes in software supply chain management. “What that means is that increasingly the developers…are the ones defining the architecture.” Ultimately that means the developer needs the capability to determine upfront whether the framework is compatible with the license policy, with security and with other requirements.

 “Everything gets more real time and the people doing the work have to be empowered to make those decisions,” said Fox. “They need to be empowered with the information to make the right decisions.”

That’s especially critical, he said, because these tasks are essential when software relies heavily on open-source components. The constant evolution of these pre-built third-party components can lead to vulnerabilities, generating risks to application security. Without the proper smart tools to identify code quality, to flag vulnerabilities and to fix them in a way that is policy-compliant—functions that can be accomplished automatically—developers may be unable to track or fix any of these issues and still meet deadlines—if at all.

By being integrated into the feedback loop, the tools create the safety net right from the start. Machine learning can bring results such as a download being intercepted and found noncompliant with policy or a download discovered to be potentially malicious. The same is true for new releases of the components: They may have elements that appear suspicious or originate from a part of the world where such releases are of a questionable nature, Fox said. The feedback message that “this transaction is not characteristic for you” blocks the download and prevents its use.

The advent of these capabilities highlights even more how inefficient the older model of software development was because, for one thing, those processes customarily used to scan code would focus solely on the custom code, the smaller portion of the code base. The scans would not take into account anything open source, which could account for as much as 80 percent of the code base, said Fox.

To make matters worse, he said, legal, security and other professionals within the organization were usually unaware that this issue even existed — even if the developers themselves did.

“In 2011 or so when we were really starting to solve this problem, we had financial organizations downloading 60,000 components a year and we talked to them and said ‘we see you are using a lot of open source.’ They said they weren’t using open source. They were unaware they were using open source, not recognizing that in the banking training algorithm platform they turned out, 80 percent of that code was open source.”

In the years that followed, progressive organizations have come to recognize that the legacy model did not work and the best solution was to turn directly to the developer, said Fox.

“Forward-leaning organizations are starting to look at this as proper dependency management, not just picking good frameworks but considering the legal and quality issues, all the way down the dependency stack,” he said.

The idea of bringing everything to the developer’s domain in a cohesive, integrated way is finally starting to take hold, he said. This also accepts the reality that open-source libraries can — and should — continue to be a source of efficiency without becoming a source of compromise or threat. It also provides better insurance against common mode failure. Making these better choices upfront means doing less work later, he said.

Fox acknowledges that such a change in the model relies heavily on buy-in from the developers who will, of course, necessarily be taking on those additional responsibilities.

 “Developers will be naturally suspicious of anything coming from outside. They have a long history of being burned by bad tools,” he said.

He believes, however, that developers want to solve the overall problems and that they care about what they’re doing. It is a big plus for developers to not have to wait six weeks for the go-ahead from someone in another building, or perhaps another country, before they can proceed, he said.

And ultimately, he said: “They’re going to have less stuff to chase down later.”

Content provided by SD Times and Sonatype

The post Empower developers for broader role appeared first on SD Times.

According to Fox and Poole, one of the biggest struggles for developers entrusted with security practices is that they were not originally trained in the security field. This lack of proper training leads to mismatched expectations on both ends. When two teams have to work together but do not speak the same language, this is an almost unavoidable problem. 

A key solution to this problem would be for organizations to better enable their developers to understand security practices. Investing time into this would help to bridge the gap between development and security and make for a better outcome in the long run. 

Sonatype provides tools to developers to make this integration of security easier, but according to Fox and Poole, organizations merely providing these tools is not enough, they have to make them understandable and accessible to their developers in order to see the desired results. 

According to Fox and Poole, as the developer domain changes, developers have a right to ask their organizations to enable them to provide long-term solutions to the problems they are now facing. They see the shift of security to developers as a positive thing, but only if the proper tools and training are in place. 

“We have so much opportunity and so much stuff that will help, but we’ve been educated for a long time not to go looking for it,” Poole said, “And now is the time to turn that around and start putting effort into education… and taking a good look at the tools that are out there and seeing how much they can help you,” he concluded.

To learn more about the expanding developer domain into the world of security, watch the full talk “The Broad Responsibilities of the Expanding Developer Domain” on demand now.

The post Placing security in the hands of developers appeared first on SD Times.