# Open Source Libraries and Software Supply Chain Security: An SCA and SBOM Guide **URL:** https://securesys.com.tr/en/learning/source-code-analysis/open-source-supply-chain-security-sca-sbom ![Open Source Libraries and Software Supply Chain Security: An SCA and SBOM Guide](/images/bilgi-merkezi/covers/cover-kod-07.webp) A modern software project does not consist entirely of code written from scratch by developers. On the contrary, the vast majority of applications developed today are built on open source libraries, third-party packages, frameworks, container images and external dependencies. A developer can add a fairly complex function to their application by writing only a few lines of code. Many operations such as: - authentication, - PDF generation, - image processing, - JSON parsing, - logging, - database access, - encryption, - network communication can be carried out through ready-made libraries. This approach significantly increases the speed of software development. But it brings a new security question with it: #### How much of the code we use did we actually write? And a second, more important question: #### How do we know the code we did not write is secure? An application's developer-written source code may be entirely secure. SAST may produce no critical findings. Manual code analysis may be successful. But a critical vulnerability may exist in a third-party library the application uses. In that case the attacker does not use an error in your code directly. They target the vulnerability inside the dependency you use. In modern software security this area is generally assessed under: #### Software Supply Chain Security . Two of the most important components of this security model are the: #### SCA – Software Composition Analysis and #### SBOM – Software Bill of Materials approaches. SCA aims to analyse the third-party components in use and their known security risks. SBOM makes visible which software components an application consists of. These two approaches are becoming indispensable parts of modern Application Security programmes. ### \1. What Is the Software Supply Chain? The software supply chain is the chain covering all the components, tools and processes used from a piece of software's development through to its arrival in the production environment. This chain does not consist only of the source code the developer writes. A web application's software supply chain may include: - Open source libraries - Frameworks - Package managers - Build tools - CI/CD systems - Container images - Artifact repositories - Git platforms - Cloud services - Third-party APIs A security problem in any of these can affect the whole security of the application. Modern software security therefore no longer asks only: **"Is the code we wrote secure?"** It also asks: **"Are all the components that make up our software secure?"** ### \2. How Much Open Source Do Modern Applications Use? The modern software development ecosystem rests largely on open source components. Java developers may use Maven or Gradle. JavaScript developers can install packages through npm. pip can be used in Python projects. NuGet packages may be preferred in the .NET ecosystem. Composer can be used in PHP applications. A developer can pull hundreds of different code components into their project with a single command. For example, the command: npm install package-name may not install only the package you want. It can automatically download the other packages that package needs too. This chain can sometimes consist of dozens or even hundreds of dependencies. As a result, a single library a developer adds to their project can actually bring a much larger software ecosystem with it. ### \3. What Is a Dependency? A dependency is an external software component a piece of software needs in order to run. A developer might use a JSON parser library to process JSON data, for example. That library then becomes a dependency of the application. Similarly: - a logging library, - an authentication framework, - a database driver, - an HTTP client, - an image processing library can be among the application's dependencies. These dependencies make software development easier. But at the same time they can create new attack surfaces. ### \4. What Is a Direct Dependency? A direct dependency is a component the developer has added to the project directly. A developer might add this package to the project file, for example: framework-x framework-x is then a direct dependency. The developer has chosen this package. They have determined its version. They use it directly inside the application. But security risk does not consist only of directly added packages. The real complexity begins here. ### \5. What Is a Transitive Dependency? A transitive dependency refers to the other dependencies a package you use directly needs. For example: You may be using: #### Package A . Package A may in turn use: #### Package B and #### Package C . And Package C may use: #### Package D . The real dependency chain therefore becomes: **Application → A → B → C → D** You may never have chosen Package D directly. But it is nonetheless present inside your application. If a critical vulnerability is found in Package D, your application can be affected. Transitive dependency management is therefore one of the most important topics in Software Supply Chain Security. ### \6. What Happens if a Vulnerability Is Found in a Dependency? When a vulnerability is detected in a third-party component, it is generally announced by the project in question or by security researchers. A CVE can be assigned to that vulnerability. A Remote Code Execution problem may be found in a particular version range of a particular library, for example. After the vulnerability is disclosed publicly, attackers can begin scanning for vulnerable systems. At that point the question the organisation must answer quickly is: #### Are we using this library? If the organisation has hundreds of applications, answering that question manually can be quite difficult. SBOM and SCA gain their value at exactly that point. ### \7. What Is a CVE? CVE — **Common Vulnerabilities and Exposures** — is the system used to describe publicly disclosed vulnerabilities in a standard way. A unique CVE number can be assigned to a vulnerability in a particular product. For example, an identifier in the format: CVE-YYYY-XXXXX can exist. Thanks to this identifier, different security systems can tell that they are talking about the same vulnerability. SCA solutions try to detect known risks by comparing the versions of the software components in use against CVE databases. ### \8. What Is SCA? SCA — **Software Composition Analysis** — is the security approach that analyses the open source and third-party software components inside an application. The basic aims of SCA are: - To detect the components in use, - To determine their versions, - To match them against known vulnerabilities, - To make risky dependencies visible, - To provide update or remediation recommendations. SCA therefore offers a different perspective from SAST. SAST analyses the code the developer wrote. SCA largely analyses the code the developer **did not write**. ### \9. The Difference Between SAST and SCA These two technologies are often confused. But their purposes are different. #### SAST Analyses the security weaknesses inside source code. It tries to detect problems such as: - SQL Injection - XSS - Command Injection - Path Traversal - insecure coding patterns . #### SCA Analyses third-party software components. It assesses, for example: - the open source packages in use, - version information, - CVEs, - licence risks, - dependency chains. A strong code security model should therefore use: #### SAST + SCA together. ### \10. How Does SCA Work? SCA solutions can use different analysis methods. One of the most common is analysing package manifest files. Files such as: - package.json - package-lock.json - pom.xml - build.gradle - requirements.txt - Pipfile - composer.json - .csproj - packages.config can be examined. These files can show which dependencies the application uses and their version information. The SCA solution compares this information against its own vulnerability intelligence database. Information like this can then be produced: **Package:** example-library **Version:** 2.1.4 **Known Vulnerability:** CVE-XXXX-XXXXX **Severity:** High **Fixed Version:** 2.1.8 This information speeds up the security team's remediation process. ### \11. Why Does the Lock File Matter? Package managers usually keep dependency versions inside a lock file. In the JavaScript ecosystem, for example, files such as: package-lock.json or: yarn.lock can be used. These files make visible the exact dependency versions the application really uses. Because the manifest file may contain a broad version definition such as: library >= 2.0 But the lock file can show which version was actually installed during the production build. This information is extremely valuable for SCA analysis. ### \12. What Is a Dependency Tree? A dependency tree is the hierarchical view of the direct and indirect dependencies in an application. A structure such as: #### Application → Library A → Library B → Library C → Library D can exist. This structure answers an important security question: #### How did the risky dependency get into the application? You may not be using Library D — which has a critical CVE — directly, for example. But Library B may be pulling it in as a dependency. To remediate, you can understand which parent package needs to be updated through the dependency tree. ### \13. Is Using a Vulnerable Dependency Always Critical? No. A CVE existing in the version of a library you use does not automatically mean your application is exploitable. This is a very important distinction. The library's vulnerability may exist only in a particular function, for example. Your application may never use that function. In that case, despite a theoretical risk, the real exploitability may be lower. In the modern SCA approach, therefore, CVE matching alone is not sufficient. **Reachability Analysis** becomes important. ### \14. What Is SCA Reachability Analysis? Reachability analysis tries to answer this question: #### Can the vulnerable code actually be used by your application? A library may contain 100 different functions, for example. The vulnerability exists in only one of them. And your application never calls that function. The risk priority can then be lowered. But if the application uses the vulnerable function directly, the risk rises. This approach is extremely valuable for separating real risks out of thousands of dependency findings. ### \15. Is CVSS Sufficient on Its Own? No. SCA tools usually use CVSS scores. CVSS is useful for understanding the technical severity level of a vulnerability. But real enterprise risk cannot be determined by the CVSS score alone. A vulnerability with a CVSS score of 9.8 may be found, for example. But the application may never use the vulnerable function. Meanwhile another vulnerability scored 7.5 may be actively usable in an internet-facing, critical payment application. In risk assessment, therefore: **CVSS + Reachability + Exposure + Business Criticality** should be assessed together. ### \16. What Is a Known Exploited Vulnerability? Some vulnerabilities are not merely theoretical. They are being used actively by attackers. Vulnerabilities of this kind should carry a higher priority. A known CVE existing in a dependency is not the same risk as a CVE attackers are actively exploiting. Exploit intelligence has become important in modern vulnerability prioritization processes. The basic question should be: #### Is this vulnerability being used actively in the real world? ### \17. Why Does Exploit Availability Matter? When a public exploit or proof of concept is published for a vulnerability, carrying out the attack can become easier. The attacker does not have to research the flaw from scratch. When determining remediation priority, therefore, criteria such as: - is a public exploit available? - is the exploit easy to use? - are there automated exploit modules? - is active exploitation observed on the internet? can be assessed. ### \18. Why Is Updating a Dependency Not Always Easy? In theory the solution is simple: **Update the risky package.** But in practice things are more complex. The new dependency version: - may contain API changes, - may be incompatible with the application, - may break other dependencies, - may create a performance problem, - may create the need for new testing. In older applications in particular, a critical dependency upgrade can turn into a large software project. Dependency management should therefore be continuous. Packages left un-updated for years create security debt. ### \19. What Is Dependency Security Debt? Dependency security debt is the accumulation over time of old, un-updated or security-risky dependencies used by the application. Update work that looks small at first turns into a bigger problem the longer it is postponed. The application may be using a version of the framework from five years ago, for example. That version is no longer supported. To update the framework, a significant part of the application must be changed. As a result the organisation may be forced to continue using the old version that contains the vulnerability. Dependency updates should therefore be part of the regular software maintenance process. ### \20. What Is an End-of-Life Dependency? If the vendor or community behind a software component no longer provides support, that component may be End-of-Life (EOL). An EOL dependency creates serious security risk. Because even if a new vulnerability is detected, a patch may not be published. SCA should therefore assess not only current CVEs but the life cycle of the component in use. A dependency may contain no CVE at present. But if it has been unsupported for six years, it can create serious risk in future. ### \21. The Risk of Abandoned Open Source Projects An open source project being popular does not always mean it is actively maintained. A project may not have been updated for years. The maintainer may have abandoned it. Security issues may go unanswered. This creates risk for enterprise use. When choosing a dependency, these questions should be assessed: - Is the project active? - When was the last release? - Are security issues being answered? - How many maintainers are there? - Is the user community active? - Are there alternatives? So dependency security is not only about checking CVEs. **The project's sustainability is a security criterion too.** ### \22. What Is a Typosquatting Attack? One of the software supply chain attacks is the **typosquatting** method. The attacker publishes a fake package whose name closely resembles that of a popular one. If the real package is: secure-library the attacker can create a package containing a small spelling error such as: secure-libary When the developer installs the wrong package, malicious code can enter the system. In this attack there does not need to be a classic vulnerability in the application's source code. The malicious dependency has entered the supply chain directly. ### \23. What Is Dependency Confusion? Dependency confusion is a supply chain attack that can arise when an organisation's private/internal package names are confused with malicious packages published in public package repositories. An organisation may be using a private package named: company-auth-library internally, for example. The attacker can publish a package with the same name to a public repository. If a misconfigured package manager prefers the public version, the malicious package can enter the build process. Internal package repository security is therefore important. ### \24. Package Repository Security The package repositories organisations use are critical infrastructure. Packages are downloaded from systems such as: - the npm registry - Maven repositories - NuGet feeds - PyPI - internal artifact repositories In enterprise environments a controlled internal proxy/repository can be used instead of direct public repository access. That way: - permitted packages, - versions, - security policies, - checksum controls can be managed more centrally. ### \25. What Is Package Integrity? Verifying whether a package is the expected and trusted content matters. Hashes and digital signatures can be used in package integrity checks. The aim is to verify that the package you downloaded: - has not been changed, - has not been manipulated, - came from a trusted source. This matters particularly for build pipeline security. ### \26. What Is a Malicious Package? Not every risk stems from a known CVE. Sometimes the package itself is malicious. The attacker can publish a malicious package directly. While being installed, this package can: - steal credentials, - read environment variables, - scan the filesystem, - send data to an external server. Checking only "does the package have a CVE?" is therefore not sufficient. Package reputation and behaviour analysis are becoming steadily more important. ### \27. Install Script Risk In some package manager ecosystems, scripts can be run automatically while a package is being installed. npm packages can contain install lifecycle scripts, for example. These scripts can run with the privileges of the developer or the CI/CD system. Using this mechanism, a malicious package can try to collect information such as: - environment variables, - SSH keys, - cloud credentials, - CI/CD tokens. Dependency installation is therefore part of the security boundary too. ### \28. Why Is the Build System Part of the Supply Chain? The developer's source code may be secure. The dependencies may be secure too. But if the build system has been compromised, the software produced can be malicious. An attacker who reaches the CI/CD pipeline can add malicious code during the build, for example. The end user may not see that code in the source code repository. But the production artifact has become malicious. Software Supply Chain Security is therefore not only dependency scanning. **Build integrity** is a critical component too. ### \29. What Is an Artifact? An artifact is the distributable software output produced at the end of the build process. For example: - JAR - WAR - DLL - executable - container image - mobile APK - package archive can each be an artifact. From a security perspective these questions matter: - Who produced the artifact? - Which source code was it produced from? - Was the build process trustworthy? - Was it changed afterwards? These questions are the foundation of modern supply chain security. ### \30. What Is Artifact Signing? Artifact signing is the digital signing of the software output produced. The aim is to verify that the artifact came from a trusted source and has not been changed afterwards. A container image or package can be signed, for example. The deployment system can permit only artifacts with a trusted signature into the production environment. This approach makes it harder for an attacker to place a malicious artifact from outside the pipeline. ### \31. What Is an SBOM? An SBOM — **Software Bill of Materials** — is a structured inventory of the components that make up a piece of software. We can liken it to a parts list in the manufacturing sector. A car manufacturer knows which parts were used to build the vehicle. Similarly, an SBOM answers: #### Which components does this software consist of? An SBOM can contain information such as: - Component Name - Version - Supplier - Package Identifier - Dependency Relationship - License This structure is extremely valuable for security visibility. ### \32. Why Does an SBOM Matter? Imagine a critical dependency vulnerability has been published. The organisation has 500 different applications. Management asks: #### Which of our applications use this library? Without an SBOM the teams may have to check the repositories one by one. That can take hours or days. If an SBOM exists, an: #### Affected Applications list can be produced quickly through the central system. SBOMs therefore increase incident response speed particularly during major security events. ### \33. Is an SBOM a Security Tool? An SBOM does not prevent a vulnerability on its own. An SBOM is in fact a **visibility and inventory mechanism.** It tells you what is inside the software. When vulnerability intelligence is added on top, which components carry risk can be seen. Therefore: #### SBOM + Vulnerability Management produce value together. ### \34. SBOM Formats Different standard formats can be used to create an SBOM. The best known among them include: - CycloneDX - SPDX The purpose of these formats is to make the SBOM data produced by different tools easier to share. When a standard structure is used, the software vendor, the customer and security platforms can all read the same component inventory. ### \35. What Is CycloneDX? CycloneDX is one of the SBOM formats developed particularly for software supply chain and security use cases. Alongside software components, dependency relationships and various security-relevant metadata can be held. It can be widely supported by Application Security and DevSecOps tools. ### \36. What Is SPDX? SPDX is another important structure used to express software components and licence information in a standard format. It has strong applications particularly for open source licence management. Which format is used in an enterprise SBOM strategy can be determined by the tools in use and the business need. ### \37. When Should an SBOM Be Produced? Preparing an SBOM manually is not sustainable. The modern approach is to generate the SBOM automatically within the CI/CD pipeline. A process can be built as: #### Source Code ↓ #### Dependency Resolution ↓ #### Build ↓ #### SCA ↓ #### SBOM Generation ↓ #### Artifact A separate SBOM can be produced for every release. Which dependencies each software version contains can then be seen clearly. ### \38. Why Does SBOM Versioning Matter? An application's dependencies change over time. Version 1.0 may use different libraries. Version 2.0 may have a different dependency set. A single static SBOM is therefore not sufficient. Every release must have its own SBOM. Which components the real version in production contains can then be seen during a security incident. ### \39. The Relationship Between SBOM and VEX A vulnerable component appearing in an SBOM does not always mean the application is genuinely affected. At this point approaches such as **VEX – Vulnerability Exploitability eXchange** can be used. VEX essentially helps a software vendor provide status information for a particular vulnerability, such as: - affected, - not affected, - fixed, - under investigation. This can reduce customers experiencing unnecessary alarm over every CVE. ### \40. Can SCA Also Find Licence Risks? Yes. One of SCA's important capabilities is the analysis of open source licences. Not all open source licences are the same. Some licences can create different obligations for enterprise product use. The licence of the component used may create obligations regarding: - commercial distribution, - source code sharing, - attribution. SCA can therefore be used not only for security but also for **Open Source Governance**. ### \41. Why Can Licence Compliance Be a Security Team Matter? Licence management may not be a direct cyber attack issue. But it is a natural part of a Software Composition Analysis programme. Because the same dependency inventory can show both security and licence risks. In large organisations the AppSec, Legal and Software Architecture teams can therefore use SCA platforms together. ### \42. How Is SCA Integrated into the CI/CD Pipeline? SCA can be run automatically in modern DevSecOps processes. For example: #### Commit ↓ #### Secret Scan ↓ #### SAST ↓ #### SCA ↓ #### Build ↓ #### Security Quality Gate ↓ #### Deploy When a critical dependency flaw is detected, the pipeline can be stopped according to policy. But as with SAST, a risk-based Quality Gate is needed here. ### \43. Should Every CVE Stop the Build? No. Otherwise software development processes become unsustainable. When creating a Quality Gate, criteria such as these can be used together: - CVSS score, - exploit availability, - known exploitation, - reachability, - application criticality, - internet exposure. For example: **Critical + Reachable + Internet Facing** a dependency vulnerability of that kind can stop the build. But a finding of: **Medium + Not Reachable + Internal Test** can be taken into the backlog. ### \44. Can SCA Produce False Positives? Yes. SCA's false positive structure is somewhat different from SAST's. The tool detects that the package is present in your application and shows that a CVE exists in that version. Technically this information may be correct. But your application may not be using the vulnerable code path. The vulnerability therefore genuinely exists inside the package but may not be exploitable as far as your application is concerned. Reachability analysis aims to reduce this problem. ### \45. Is Container Image Scanning Part of SCA? In most modern security programmes the packages inside container images are analysed too. A container image does not contain only the application's dependencies. Operating system packages can also be present. Components such as: - OpenSSL - glibc - curl - system libraries can exist inside the base image. From a container security perspective there are therefore two different layers: #### Application Dependencies and #### Operating System Packages Both must be scanned. ### \46. Base Image Risk Developers can use a base image inside a Dockerfile, such as: FROM ubuntu:... or: FROM node:... There can be hundreds of packages inside that image. If the base image has not been updated for a long time, a large number of known CVEs can be present. In container security, therefore: - a minimal base image, - a trusted registry, - regular updates, - image scanning are critical controls. ### \47. Why Does a Minimal Image Matter? The more packages there are inside a container, the more the attack surface can grow. Tools the application does not need, such as: - a shell, - a compiler, - network utilities may not need to be present in the production image. The minimal image approach does not only reduce image size. It can also reduce the attack surface. ### \48. IaC Dependency Security The software supply chain does not consist only of application packages. Infrastructure as Code projects can use modules and providers too. Terraform modules can be downloaded from third-party repositories, for example. The: - source, - version, - integrity, - trustworthiness of the IaC modules used must therefore be checked. ### \49. GitHub Action and CI/CD Plugin Risk The use of third-party actions or plugins in CI/CD pipelines is also a dependency risk. A build workflow can run an external action. That action can reach: - the repository code, - CI/CD tokens, - environment variables. Third-party CI/CD actions should therefore be taken into the supply chain security assessment too. ### \50. What Is Version Pinning? Version pinning is fixing the dependency or CI/CD action in use to a particular version. Using a fixed version such as: library: 2.4.1 can prevent an unexpected new version entering the build automatically. But the disadvantage of pinning is that updates have to be managed manually. It can therefore be used together with automated dependency update systems. ### \51. Is Automatic Dependency Update Safe? Mechanisms like Dependabot can open a pull request automatically when new dependency versions are released. This approach can speed up security patch processes. But the approach: **A new version was released → take it into production automatically** is not always safe. The new dependency must be tested. Unit tests, integration tests, security checks must be run. The best model is automatic update suggestion + controlled testing + review. ### \52. Dependency Update SLA Remediation periods can be determined for dependency security findings. According to the organisation's risk model, a process can be created as: **Critical:** Within a very short period **High:** Priority remediation **Medium:** Planned release **Low:** Backlog But the normal SLA should not be waited out for a vulnerability under active exploitation. Incident-level intervention may be needed. ### \53. Zero-Day Dependency Vulnerabilities Zero-day can describe a critical vulnerability that has no patch yet or has only just been discovered. When a zero-day is found in a dependency, updating may not always be possible. Compensating controls can be applied in that case. For example, temporary protections such as: - disabling the vulnerable function, - a WAF rule, - network restriction, - feature disablement, - input blocking can be used. But these must not take the place of a permanent patch. ### \54. What Should the First Question Be in an Urgent Dependency Incident? When a critical vulnerability is announced, the scope of impact should be determined first rather than panicking and updating every system. The basic questions are: - Are we using this dependency? - In which applications? - In which versions? - Is it in production? - Is the vulnerable function reachable? - Is the system internet-facing? - Is a public exploit available? - Is a patch available? SBOM and SCA let these questions be answered far more quickly. ### \55. Why Is a Software Asset Inventory Necessary? Dependency security cannot be managed effectively without an application inventory. The organisation should know: - which applications exist, - who owns them, - their production status, - their business criticality, - the technologies used, - the dependency structure. An Application Security programme can therefore integrate with the CMDB or application inventory. ### \56. Who Is the Dependency Owner? When a vulnerability is found, one of the most critical operational questions is: #### Who will fix it? The answer must be known in advance. For every application and repository, an: - Application Owner - Technical Owner - Security Owner can be defined. A critical SCA finding can then be assigned directly to the responsible team. ### \57. How Should SCA Findings Be Presented to Developers? A good SCA finding should not just say: **"This dependency is vulnerable."** It should present this information: - the package name, - the version in use, - the CVE, - the severity, - the dependency path, - exploitability, - the fixed version, - the recommended remediation. Information such as: **Vulnerable Package:** Library X 1.2 **Introduced Through:** Framework Y 4.1 **Fixed In:** Library X 1.5 lets the developer solve the problem faster. ### \58. Why Does the Dependency Path Matter? The risky package may not be your direct dependency. For example: #### Your App → Framework A → Utility B → Vulnerable Library C In that case the developer may not be able to update Library C directly. Moving to a new version of Framework A may be required. The SCA system showing the dependency path makes the remediation process easier. ### \59. What Is Open Source Governance? Open Source Governance is the process that determines which open source components an organisation may use and how they will be managed. An organisation's policy might include: - packages with critical CVEs may not be used, - EOL libraries may not be used, - certain licences are prohibited, - adding a new package requires review, - packages may only be downloaded from an approved repository. This approach can reduce dependency risk before any code is written. ### \60. Approved Library Catalogue Large organisations may not want developers choosing packages at random for every project. An approved library catalogue can be created instead. A particular framework for authentication, a particular library for logging, a particular library for cryptography can be standardised. This approach improves both security and software architecture. ### \61. Does a Dependency Being Popular Mean It Is Secure? No. A critical vulnerability can appear in a package downloaded millions of times too. Popularity can provide some positive signals but is not a security guarantee. When assessing, factors such as: - maintainer activity, - vulnerability history, - release frequency, - security process, - community size should be examined together. ### \62. Can a Small Dependency Create a Big Risk? Yes. This is one of the important characteristics of the software supply chain. A small utility package containing a few lines of code can be present in the dependency chain of millions of applications. When that package is compromised, it can create very wide impact. Package size is therefore not an indicator of security impact. ### \63. What Happens if a Maintainer Account Is Compromised? If an open source project's maintainer account is compromised, the attacker can publish a malicious new version. If organisations pull dependencies automatically to the latest version, the malicious package can enter their build processes. Version pinning, integrity verification and controlled updates are therefore important. ### \64. Is SAST Enough Against a Supply Chain Attack? Not always. If the malicious dependency is downloaded during the build and is not present in the source repository, SAST may not see it. Supply chain security therefore requires different layers: #### SCA #### Package Integrity #### Artifact Security #### CI/CD Security #### SBOM #### Runtime Controls This structure is more comprehensive than a single scanning tool. ### \65. Why Do SCA and Secret Scanning Matter Together? Supply chain attackers sometimes do not use a dependency vulnerability directly. Credential-stealing code can be present inside a compromised package. SCA, secret security and CI/CD security are therefore closely related. Modern AppSec must answer these three basic questions: #### Is our code secure? #### Is the code we use secure? #### Is our build and release process secure? ### \66. How Is an Enterprise SCA Programme Set Up? A practical SCA programme can be built in stages. #### Stage 1 – Visibility All repositories are scanned. A dependency inventory is produced. #### Stage 2 – Risk Classification Critical and high-risk dependencies are identified. #### Stage 3 – CI/CD Integration New dependencies are checked automatically. #### Stage 4 – Quality Gate Build policies are applied at defined risk levels. #### Stage 5 – SBOM An SBOM is created for every release. #### Stage 6 – Continuous Monitoring Existing applications are reassessed automatically when a new CVE appears. This last stage is particularly important. ### \67. Why Is Continuous Monitoring Needed After the Build? A dependency may be secure on the release date. A new vulnerability may be found six months later. Even though nothing changed in the application code, the security position has changed. Performing SCA only during the build is therefore not sufficient. Dependencies must be compared continuously against vulnerability intelligence. This approach can be thought of as: #### Continuous Software Composition Analysis ### \68. Automatic Alerts When a New CVE Appears In an ideal system, when a new vulnerability is published the organisation's security platform compares it automatically against the existing SBOM and dependency inventory. For example: **A new critical CVE has been published.** The system can automatically provide information such as: **18 applications are affected.** **7 of them are production.** **3 are internet-facing.** This visibility significantly speeds up incident response. ### \69. Should an SBOM Be Given to the Customer? This can vary according to contract, sector and security requirements. Some customers may request an SBOM from their supplier. Knowing which components software consists of can become important particularly in critical infrastructure and regulated sectors. But because the SBOM itself contains detailed information about software architecture, sharing policies should be determined carefully. ### \70. Is an SBOM Sensitive Information? An SBOM does not directly contain passwords, but it can provide valuable reconnaissance information from an attacker's perspective. Information about the: - framework, - packages, - versions in use can be seen. SBOM access should therefore be controlled according to organisational policy. The SBOM shared with a customer and the SBOM for internal use can have different scopes. ### \71. Software Supply Chain Risk Management Enterprise supply chain security is not a single technology project. The following layers should be assessed together: #### Source Code SAST and manual analysis. #### Secrets Secret Scanning and Vault. #### Dependencies SCA. #### Build CI/CD Security. #### Artifact Signing and Integrity. #### Inventory SBOM. #### Deployment Policy Enforcement. #### Monitoring Continuous Vulnerability Intelligence. All these layers together form the software supply chain. ### \72. Where Does SCA Sit Within Source Code Analysis? Source code analysis should not be thought of as assessing only the code the developer wrote. Modern code security can be addressed in three basic layers: #### First-Party Code Code written by the organisation's developers. #### Third-Party Code Open source and commercial dependencies. #### Build & Runtime Components Container, OS package and deployment components. SAST covers the first area, SCA the second, and container and infrastructure scanning the third. ### \73. Modern AppSec Is Incomplete Without SCA and SBOM If 80 per cent of an application consists of third-party code, analysing only the 20 per cent the organisation wrote is not sufficient. A modern Application Security programme should therefore use this combination: **SAST → Our own code** **SCA → The code we use** **Secret Scanning → The access keys inside the code** **SBOM → The software's full component inventory** These four approaches together provide the basic visibility of code security. ### The SecureSys SCA and Software Supply Chain Security Approach At SecureSys we do not treat source code security as merely the analysis of code written by the organisation's own developers. Because a significant part of modern applications consists of third-party and open source components, the security risks of those dependencies are an inseparable part of the Application Security process. Depending on project scope, the layers: #### SAST, SCA, Secret Scanning, SBOM, Container Security and CI/CD Security can be assessed together. In SCA work it is not sufficient merely to say: **"There is a CVE in this dependency."** In a real risk assessment, factors such as: - the version in use, - the dependency path, - reachability, - exploit availability, - internet exposure, - application criticality must be assessed together. In the same way, an SBOM should not remain merely an inventory output. It should be turned into living security data that allows existing software assets to be reassessed quickly when new vulnerabilities emerge. Because in modern software security the question: **"Which code did we write?"** is no longer sufficient on its own. You also need to know the answer to: **"Which code did we bring into our system?"** ### Frequently Asked Questions #### What is SCA? SCA is the abbreviation of Software Composition Analysis. It detects the open source and third-party software components used in an application and analyses them for known vulnerabilities and licence risks. #### What is the difference between SAST and SCA? SAST analyses the security weaknesses inside source code written by developers. SCA assesses third-party dependencies and open source components. #### What is a dependency? It is an external library or software component a piece of software needs in order to run. #### What is a transitive dependency? They are the other dependencies that a dependency you use directly needs itself. #### What is an SBOM? SBOM is the abbreviation of Software Bill of Materials. It is a structured software inventory showing which components and versions a piece of software consists of. #### Does an SBOM find vulnerabilities? Not on its own. An SBOM makes software components visible. When used together with vulnerability intelligence or SCA, risky components can be detected. #### Does a CVE in a dependency mean the application is definitely vulnerable? Not always. Reachability factors, such as whether the code path containing the vulnerability is used by the application, must be assessed. #### Can SCA be integrated into CI/CD? Yes. Dependency analysis can be run automatically at the build and pull request stages. #### Can SCA perform licence checks? Many SCA solutions also analyse open source licences and can provide information about licence compliance risks. #### Can container images be scanned with SCA? Yes. Both application dependencies and operating system packages inside a container image can be analysed for vulnerabilities. #### Should an SBOM be produced for every release? Preferably yes. Because the dependencies and versions in use can change with every release. The real software composition in production is then tracked more accurately. #### Is using open source insecure? No. Open source software is a fundamental part of the modern software ecosystem. The risk lies in not knowing which components are used and in not managing the security life cycle of dependencies. ### Conclusion: The Code You Did Not Write Is Also Your Attack Surface In a modern software project a developer may write thousands of lines of code. But the total code the application uses can be many times that. Frameworks, open source libraries, packages, container images, CI/CD components are all part of the application's real attack surface. Therefore the statement: **"There are no vulnerabilities in our code."** does not on its own mean security. Because the attacker does not have to attack the code you wrote. They can target a vulnerability in a dependency you use. They can use a compromised package. They can take advantage of a flaw in an old library. They can exploit a third-party component in the build pipeline. Modern code security must therefore keep asking three basic questions: #### Is the code we wrote ourselves secure? #### Is the code we use secure? #### Is the supply chain we produce the software with secure? SAST answers the first question, SCA the second, and by making the components you use visible, SBOM answers an important part of the third. But there is a larger goal here: Not merely reacting when a vulnerability appears, but **knowing at every moment what the software consists of.** Because you cannot update a dependency you do not know about. You cannot manage a vulnerability in a component you do not know about. You cannot protect a software supply chain you do not know about. One of the basic principles of modern Application Security is therefore this: **The code you did not write is as much your security responsibility as the code you did.**