Open-source software has become fundamental to modern application development. But as organisations depend on thousands of third-party components, managing vulnerabilities, malicious packages and licensing risks has become a critical software supply-chain challenge.
Modern software is rarely built entirely from scratch.
Developers depend on open-source libraries, frameworks, packages and third-party components to accelerate development and bring applications to market faster.
This model has transformed software engineering.
But it has also created a new security challenge.
Every external component introduced into an application becomes part of the organisation’s software supply chain.
If that component contains a known vulnerability, malicious code or an incompatible licence, the risk can travel directly into the final application.
This makes open-source governance an increasingly important part of enterprise cybersecurity.
In an interview with Express Computer, Prasanna Raghavendra, Senior Director of R&D at JFrog India, discussed the risks associated with open-source software and how organisations can introduce stronger controls without slowing developers down.
Open Source Has Become Essential to Software Development
The modern developer ecosystem depends heavily on open source.
Developers can use existing components instead of rebuilding common functionality from the ground up.
This improves productivity and allows development teams to move faster.
But the scale of this ecosystem creates a management problem.
An enterprise may need to understand:
- Which open-source packages are being used?
- Which versions are deployed?
- Where are those packages being used?
- Do they contain known vulnerabilities?
- Are they malicious?
- What licences apply to them?
- Are newer and safer versions available?
- What dependencies exist between components?
Without central visibility, answering these questions can become extremely difficult.
Known Vulnerabilities Are a Major Risk
One of the most significant risks associated with open-source software is a known vulnerability.
A vulnerability may exist within a particular version of a component even though the software itself is widely used.
If an organisation continues using the vulnerable version, attackers may eventually exploit the weakness.
The problem becomes more serious when organisations have thousands of dependencies.
A vulnerability discovered today may affect software that was deployed months or years ago.
Security teams therefore need visibility into dependencies throughout the software lifecycle.
The Software Supply Chain Is Now an Attack Surface
Cybersecurity is no longer limited to protecting an organisation’s servers, endpoints and networks.
The software supply chain has become another major attack surface.
An attacker does not necessarily need to compromise the target organisation directly.
They may instead attempt to compromise a third-party package, dependency, repository or software component that the organisation trusts.
Once that component enters the development environment, the attacker may gain a path into downstream applications.
This makes software supply-chain security a strategic cybersecurity issue.
Malicious Packages Create Another Layer of Risk
Not every open-source security problem comes from an accidental coding mistake.
Attackers can deliberately create malicious packages designed to look legitimate.
A developer may download such a package believing it to be a normal open-source dependency.
Once incorporated into a development environment, malicious code can create serious security consequences.
Centralised screening can help organisations identify risky packages before they enter the development pipeline.
This is one of the principles behind JFrog Curation, which the interview describes as a mechanism for evaluating open-source packages against security, operational and licensing policies before they enter an organisation’s development environment.
Security Cannot Be Added Only at the End
Traditional application security often involved scanning software after developers had already built it.
That approach creates a problem.
If a vulnerability is discovered late in the development cycle, developers may need to:
Find → Fix → Test → Rebuild → Retest → Release
This takes time.
It can also create friction between security and development teams.
A more effective approach is to identify risky dependencies before they become deeply embedded in the application.
This is the essence of the shift-left security approach.
Security becomes part of the development process rather than a final checkpoint.
The Developer Experience Matters
Security controls that constantly interrupt developers are unlikely to be adopted successfully.
If developers have to manually investigate every package before downloading it, the process becomes slow and frustrating.
The better approach is automation.
A central policy engine can automatically evaluate packages and allow approved components while blocking those that violate security or compliance rules.
The developer only needs to intervene when a genuine problem is identified.
This creates a balance between:
Security + Developer Productivity
rather than treating them as competing objectives.
Three Major Categories of Open-Source Risk
The interview identifies three broad areas that organisations need to manage.
1. Security Risk
This includes malicious packages and known vulnerabilities.
A vulnerable component can expose an application to exploitation and potentially compromise data or systems.
2. Operational Risk
Some components may be outdated, unsupported or difficult to maintain.
An organisation may find itself depending on a package that has not been updated for a long period.
This can create long-term maintenance and security problems.
3. Licensing Risk
Open-source software comes with different licence obligations.
Organisations need to understand the licences associated with their dependencies and ensure that their use complies with applicable terms.
As the number of components increases, managing these obligations becomes more complicated.
SBOMs Are Becoming Increasingly Important
A Software Bill of Materials (SBOM) can be thought of as an ingredients list for software.
It provides visibility into the components that make up an application.
This can help organisations understand their software supply chain and respond more quickly when a vulnerability is discovered.
Imagine that a widely used open-source library is suddenly found to contain a critical vulnerability.
An organisation with an accurate SBOM can ask:
Where is this component being used?
Which applications are affected?
Which customers or systems could be exposed?
Without that visibility, security teams may have to search manually across multiple development environments.
SBOMs therefore have an important role in modern software governance.
Security Policies Need to Be Centralised
Large organisations often have hundreds or thousands of developers.
Allowing every developer to independently decide which open-source components are acceptable can create inconsistent security practices.
A centralised policy approach can define rules such as:
- Block malicious packages
- Block critical vulnerabilities
- Restrict certain licence types
- Prevent use of unsupported versions
- Require approved package versions
- Record package activity for auditing
This provides consistency across the software development environment.
Fixing Existing Vulnerabilities Is Different From Preventing New Ones
Organisations often face a large backlog of vulnerabilities.
Trying to fix everything immediately may not be realistic.
A more practical strategy is to divide the problem into two areas.
First: prevent new critical risks from entering the environment.
Second: systematically remediate existing vulnerabilities according to priority and defined SLAs.
This prevents the vulnerability backlog from continuously growing while security teams work through existing issues.
Security and Development Need to Work Together
Open-source security should not become a battle between developers and security teams.
Developers want speed.
Security teams want risk reduction.
Both objectives are legitimate.
The solution is to build security controls that operate automatically within the development workflow.
When risky packages are automatically identified and developers receive actionable remediation guidance, security becomes part of development rather than an obstacle to it.
Compliance Is Becoming More Important
Software supply-chain security is also becoming increasingly relevant to compliance.
Highly regulated industries such as financial services and insurance may need detailed records of software components, security controls and software releases.
Organisations may also need to demonstrate compliance with internal security policies and industry standards.
An auditable software supply chain can therefore provide value beyond cybersecurity.
It can support:
Security + Compliance + Governance + Risk Management
The Future Is Secure-by-Design Software
The broader direction of software security is increasingly clear.
Security cannot be treated as something that happens after development.
It needs to be embedded into the process from the beginning.
That means:
Secure Code → Secure Dependencies → Secure Build → Secure Release → Secure Runtime
Open-source components need to be part of that chain.
The earlier an organisation can identify a malicious package or vulnerable dependency, the less expensive and disruptive remediation is likely to be.
Conclusion
Open-source software has become one of the foundations of modern digital innovation.
It allows developers to build applications faster, reuse proven components and accelerate innovation.
But that convenience comes with responsibility.
Organisations need visibility into their dependencies, strong policies for accepting open-source components and processes for identifying vulnerabilities before they reach production.
They also need to manage licensing, operational risks and software supply-chain compliance.
The most effective approach is not to avoid open source.
It is to use open source intelligently and securely.
With automated security controls, SBOM visibility, centralised governance and a strong DevSecOps culture, organisations can continue benefiting from the open-source ecosystem while reducing the risks it introduces.
The future of software development will depend on both speed and trust.
And securing the software supply chain is becoming essential to achieving both.
