# Software Supply Chain Security & SBOM Hizmetleri

**URL:** https://securesys.com.tr/tr/hizmetler/software-supply-chain-security-sbom

Modern yazılımlar yalnızca kurumların kendi geliştiricileri tarafından yazılan kaynak kodlardan oluşmaz. Açık kaynak kütüphaneler, üçüncü taraf paketler, framework'ler, container image'ları, build araçları, CI/CD pipeline'ları, package repository'leri ve dış kaynaklı yazılım bileşenleri modern uygulamaların önemli bölümünü oluşturur.

Bu durum yazılım geliştirme süreçlerini hızlandırırken yeni bir güvenlik alanını da beraberinde getirir: **Software Supply Chain Security – Yazılım Tedarik Zinciri Güvenliği**.

Bir uygulamanın kendi kaynak kodunun güvenli olması, uygulamanın tamamının güvenli olduğu anlamına gelmez. Uygulamanın kullandığı bir açık kaynak kütüphanede kritik güvenlik açığı bulunabilir, build pipeline ele geçirilebilir, zararlı bir package dependency olarak projeye dahil edilebilir veya güvenilir olduğu düşünülen bir container image içerisinde riskli bileşenler bulunabilir.

Bu nedenle modern uygulama güvenliği yaklaşımında yalnızca kaynak kod değil, yazılımın üretildiği ve dağıtıldığı tüm zincirin korunması gerekir.

SecureSys **Software Supply Chain Security & SBOM Hizmetleri** kapsamında;

- Software Bill of Materials – SBOM,
- Software Composition Analysis – SCA,
- open source dependency security,
- third-party component security,
- package security,
- repository security,
- CI/CD pipeline security,
- build security,
- artifact security,
- container image security,
- secret scanning,
- vulnerability management,
- dependency monitoring

süreçlerini birlikte ele alır.

Temel yaklaşımımız:

**Developer → Source Code → Dependency → Repository → CI/CD → Build → Artifact → Container → Registry → Deployment → Production**

zincirinin tamamında güvenlik görünürlüğü oluşturmaktır.

### Software Supply Chain Nedir?

Software Supply Chain, bir yazılım ürününün geliştirilmesi, build edilmesi, paketlenmesi, dağıtılması ve production ortamında çalıştırılması sırasında kullanılan tüm bileşenleri ve süreçleri ifade eder.

Modern bir yazılım tedarik zinciri içerisinde;

- developer,
- source code,
- Git repository,
- open source libraries,
- third-party packages,
- package manager,
- build system,
- CI/CD pipeline,
- container image,
- artifact repository,
- container registry,
- deployment platform,
- cloud infrastructure

gibi çok sayıda bileşen bulunabilir.

Bu zincirin herhangi bir noktasındaki güvenlik problemi nihai yazılım ürününü etkileyebilir.

### Software Supply Chain Security Nedir?

Software Supply Chain Security, yazılım geliştirme ve dağıtım zincirinin tamamının saldırılara, manipülasyona ve güvenlik açıklarına karşı korunmasını amaçlayan güvenlik yaklaşımıdır.

Amaç yalnızca uygulama kodunu taramak değildir.

Aynı zamanda;

- kodun nereden geldiğini,
- hangi dependency'lerin kullanıldığını,
- build işleminin nasıl yapıldığını,
- artifact'ın değiştirilip değiştirilmediğini,
- hangi container image'ın production'a alındığını

görünür hale getirmektir.

### Yazılım Tedarik Zinciri Neden Kritik Hale Geldi?

Modern yazılım geliştirme süreçlerinde uygulamaların önemli bölümü hazır bileşenler kullanılarak geliştirilmektedir.

Örneğin bir uygulama;

- 50.000 satır kurum içi kod,
- yüzlerce open source package,
- onlarca transitive dependency

içerebilir.

Bu durumda kurum yalnızca kendi yazdığı koddan değil, kullandığı tüm üçüncü taraf bileşenlerden de etkilenir.

Tek bir kritik dependency açığı yüzlerce uygulamayı etkileyebilir.

### Third-Party Software Risk

Kurumların kullandığı yazılımlarda üçüncü taraf bileşenlerin güvenliği önemli bir risk alanıdır.

Third-party component içerisinde;

- vulnerability,
- malicious code,
- unsupported package,
- outdated version,
- license risk

bulunabilir.

SecureSys Software Supply Chain Security hizmeti bu risklerin görünür hale getirilmesine yardımcı olur.

### Open Source Security

Open source yazılımlar modern uygulama geliştirme ekosisteminin temel bileşenlerindendir.

Ancak açık kaynak kullanımı kontrolsüz bırakıldığında;

- güvenlik açığı bulunan paketler,
- güncellenmeyen dependency'ler,
- terk edilmiş projeler,
- zararlı paketler

uygulamalara dahil olabilir.

Bu nedenle open source kullanımının merkezi olarak yönetilmesi gerekir.

### Software Composition Analysis – SCA

Software Composition Analysis, uygulamalarda kullanılan open source ve third-party bileşenlerin analiz edilmesini sağlar.

SCA araçları;

- package,
- library,
- dependency,
- version,
- known vulnerability,
- license

bilgilerini analiz edebilir.

Bu sayede kurum hangi uygulamanın hangi bileşeni kullandığını görebilir.

### SCA Neden Gereklidir?

Kaynak kod güvenlik analizleri çoğunlukla kurumun yazdığı kodu değerlendirir.

Ancak modern uygulamalardaki risklerin önemli bölümü third-party dependency'lerden gelebilir.

SCA sayesinde;

**Application → Component → Version → Vulnerability**

ilişkisi oluşturulabilir.

### Direct Dependency Nedir?

Developer tarafından uygulamaya doğrudan eklenen package'lar direct dependency olarak adlandırılır.

Örneğin bir Node.js projesine developer tarafından eklenen bir npm package direct dependency olabilir.

### Transitive Dependency Nedir?

Bir package'ın kendi içerisinde kullandığı başka package'lar transitive dependency olarak adlandırılır.

Developer bu bileşenleri doğrudan eklemese bile uygulamanın dependency ağacının parçası haline gelirler.

Bu nedenle yalnızca doğrudan dependency'lerin kontrol edilmesi yeterli değildir.

### Dependency Tree Analizi

SecureSys SCA yaklaşımında uygulamanın dependency ağacı analiz edilebilir.

Örneğin:

#### Application

↓

#### Package A

↓

#### Package B

↓

#### Vulnerable Package C

Bu sayede kritik vulnerability'nin uygulamaya hangi dependency üzerinden geldiği belirlenebilir.

### SBOM Nedir?

**SBOM – Software Bill of Materials**, bir yazılım ürününün içerisinde bulunan bileşenlerin yapılandırılmış envanteridir.

SBOM, fiziksel ürünlerde kullanılan Bill of Materials yaklaşımının yazılım dünyasındaki karşılığıdır.

Bir SBOM içerisinde;

- component name,
- component version,
- package,
- supplier,
- dependency relationship,
- identifier

gibi bilgiler bulunabilir.

### SBOM Neden Önemlidir?

Bir güvenlik açığı yayınlandığında kurumların ilk sorusu genellikle şudur:

#### “Bu bileşeni biz kullanıyor muyuz?”

SBOM bulunmayan yapılarda bu sorunun cevabını bulmak günler sürebilir.

SBOM sayesinde;

**Vulnerability → Component → Application**

ilişkisi daha hızlı kurulabilir.

### SBOM ile Yazılım Envanteri

SBOM yalnızca vulnerability management için kullanılmaz.

Aynı zamanda kurumun yazılım bileşen envanterinin oluşturulmasına yardımcı olabilir.

Örneğin kurum içerisinde 200 uygulama varsa her uygulamanın hangi;

- framework,
- package,
- library,
- component

kullandığı merkezi olarak takip edilebilir.

### SBOM Formatları

SBOM verileri farklı standart formatlarda oluşturulabilir.

Yaygın formatlar arasında;

- CycloneDX,
- SPDX

bulunmaktadır.

Bu formatlar yazılım bileşen bilgilerinin makine tarafından okunabilir şekilde paylaşılmasına yardımcı olur.

### CycloneDX SBOM

CycloneDX, özellikle software supply chain ve application security kullanım senaryolarında yaygın kullanılan SBOM formatlarından biridir.

Uygulama bileşenleri ve dependency ilişkileri yapılandırılmış biçimde tanımlanabilir.

### SPDX SBOM

SPDX, yazılım bileşenleri, lisanslar ve paket bilgileri için kullanılan açık standartlardan biridir.

Kurumsal SBOM süreçlerinde CycloneDX veya SPDX formatları değerlendirilebilir.

### SBOM Oluşturma Hizmeti

SecureSys mevcut uygulamalar için SBOM oluşturma süreçleri tasarlayabilir.

SBOM;

- source code,
- build pipeline,
- container image,
- package manifest

üzerinden üretilebilir.

### Otomatik SBOM Oluşturma

Modern [DevSecOps](/tr/hizmetler/devops-devsecops-hizmetleri) ortamlarında SBOM manuel olarak oluşturulmamalıdır.

CI/CD pipeline içerisinde her build sonrasında otomatik SBOM üretilebilir.

Örnek:

#### Git Commit

↓

#### Build

↓

#### SCA

↓

#### SBOM Generation

↓

#### Artifact

Bu sayede her yazılım versiyonu için güncel SBOM oluşturulabilir.

### Continuous SBOM

Yazılım dependency'leri sürekli değiştiği için SBOM tek seferlik belge olarak değerlendirilmemelidir.

Her release veya build sonrasında SBOM güncellenebilir.

Bu yaklaşım **Continuous SBOM** olarak ele alınabilir.

### SBOM Repository

Kurum içerisinde oluşturulan SBOM'lar merkezi repository üzerinde saklanabilir.

Örneğin:

**Application A → Version 3.1 → SBOM**

**Application A → Version 3.2 → SBOM**

**Application B → Version 7.0 → SBOM**

şeklinde versiyon bazlı kayıt tutulabilir.

### SBOM ve Vulnerability Intelligence

SBOM verileri vulnerability intelligence kaynaklarıyla ilişkilendirilebilir.

Yeni CVE yayınlandığında ilgili component'i kullanan uygulamalar otomatik olarak belirlenebilir.

Bu model:

**New CVE → Component Match → Affected Applications → Security Alert**

şeklinde çalışabilir.

### Vulnerability Exploitability eXchange – VEX

SBOM bir bileşenin uygulama içerisinde bulunduğunu gösterebilir.

Ancak bu bileşenin vulnerability'sinin uygulamada gerçekten exploitable olup olmadığı ayrı bir konudur.

VEX yaklaşımı vulnerability'nin belirli ürün veya uygulama üzerindeki exploitability durumunun ifade edilmesine yardımcı olur.

### SBOM ve VEX Birlikte Kullanımı

SBOM:

#### Hangi bileşen var?

sorusuna cevap verir.

VEX ise:

#### Bu vulnerability bizi gerçekten etkiliyor mu?

sorusunun değerlendirilmesine yardımcı olur.

Bu iki yaklaşım birlikte kullanıldığında vulnerability management süreçleri daha doğru önceliklendirilebilir.

### CVE Takibi

SCA ve SBOM sistemleri bilinen CVE kayıtlarıyla ilişkilendirilebilir.

Yeni vulnerability yayınlandığında etkilenen dependency'ler tespit edilebilir.

### CVSS Risk Değerlendirmesi

Vulnerability severity değerlendirmesinde CVSS skorları kullanılabilir.

Ancak yalnızca CVSS skoruna göre aksiyon almak her zaman yeterli değildir.

### EPSS ile Exploit Olasılığı

EPSS gibi modeller vulnerability'nin gerçek dünyada exploit edilme olasılığına yönelik ek risk göstergesi sağlayabilir.

SecureSys vulnerability prioritization sürecinde;

**CVSS + Exploitability + Asset Criticality + Exposure**

faktörlerini birlikte değerlendirebilir.

### Risk-Based Vulnerability Management

Örneğin internet-facing kritik uygulamadaki High vulnerability, internal test ortamındaki Critical vulnerability'den daha yüksek operasyonel önceliğe sahip olabilir.

Bu nedenle SecureSys risk bazlı remediation yaklaşımı uygulayabilir.

### Dependency Vulnerability Monitoring

Dependency güvenliği yalnızca build sırasında kontrol edilmemelidir.

Bugün güvenli olan package için yarın yeni bir CVE yayınlanabilir.

Bu nedenle production uygulamalarındaki dependency'lerin sürekli izlenmesi önemlidir.

### Continuous Dependency Monitoring

SecureSys;

**Application Inventory → SBOM → Vulnerability Feed → Continuous Monitoring**

modeliyle sürekli dependency güvenliği oluşturabilir.

### Dependency Update Management

Vulnerability bulunan dependency'nin yeni versiyona yükseltilmesi gerekebilir.

Ancak kontrolsüz dependency update uygulamanın çalışmasını bozabilir.

Bu nedenle;

- vulnerability,
- compatibility,
- testing,
- release

süreçleri birlikte yönetilmelidir.

### Package Security

Modern yazılımlarda;

- npm,
- PyPI,
- Maven,
- NuGet,
- RubyGems

gibi package repository'leri yoğun olarak kullanılmaktadır.

Package güvenliği Software Supply Chain Security'nin önemli parçasıdır.

### Malicious Package Riski

Saldırganlar açık package repository'lerine zararlı paketler yükleyebilir.

Developer yanlışlıkla bu package'ı projeye dahil edebilir.

Bu nedenle package source'larının kontrol edilmesi gerekir.

### Typosquatting Saldırıları

Typosquatting saldırılarında saldırgan popüler bir package adına benzeyen isimle zararlı package yayınlar.

Developer package adını yanlış yazdığında zararlı bileşeni indirebilir.

### Dependency Confusion

Dependency Confusion saldırılarında private package isimleri public repository üzerinde yayınlanarak build sisteminin saldırgan tarafından hazırlanan package'ı indirmesi hedeflenebilir.

Bu risk özellikle public ve private package repository'lerin birlikte kullanıldığı yapılarda önemlidir.

### Private Package Repository

SecureSys kurum içerisinde private package repository oluşturulmasına destek sağlayabilir.

Bu yapı;

- Maven,
- npm,
- NuGet,
- PyPI

package'larının kontrollü şekilde kullanılmasını sağlayabilir.

### Repository Proxy

Developer ekiplerinin doğrudan internet üzerindeki package repository'lere erişmesi yerine merkezi proxy kullanılabilir.

Örnek:

**Developer → Private Repository → Approved External Repository**

Bu yapı package kullanımının merkezi kontrol edilmesini sağlar.

### Package Allowlist

Kurum içerisinde yalnızca onaylanmış package'ların kullanılmasına yönelik allowlist yaklaşımı uygulanabilir.

### Package Blocklist

Kritik vulnerability veya güvenlik riski bulunan package'ların kullanımı merkezi olarak engellenebilir.

### Git Repository Security

Software Supply Chain Security kaynak kod repository'sinden başlar.

Git repository üzerinde;

- MFA,
- branch protection,
- access control,
- code review,
- commit protection,
- secret scanning

kontrolleri uygulanabilir.

### Branch Protection

Production branch'e doğrudan commit yapılması engellenebilir.

Değişikliklerin;

**Developer → Pull/Merge Request → Review → Approval → Merge**

sürecinden geçmesi sağlanabilir.

### Code Review

Kritik değişikliklerin en az ikinci bir developer tarafından incelenmesi yazılım güvenliği açısından önemli bir kontroldür.

### Signed Commits

Commit'lerin güvenilir geliştiriciler tarafından oluşturulduğunu doğrulamak amacıyla commit signing mekanizmaları kullanılabilir.

### Secret Scanning

Repository içerisinde;

- API key,
- access token,
- password,
- private key,
- cloud credential

bulunması ciddi güvenlik riski oluşturur.

Secret scanning araçları repository ve commit history içerisinde hassas bilgileri tespit edebilir.

### Pre-Commit Security

Güvenlik kontrollerinin developer commit yapmadan önce çalıştırılması mümkündür.

Pre-commit hook ile;

- secret,
- code quality,
- basic security

kontrolleri yapılabilir.

### CI/CD Supply Chain Security

CI/CD pipeline yazılım tedarik zincirinin en kritik bileşenlerinden biridir.

Pipeline'ın ele geçirilmesi saldırgana;

- source code,
- build system,
- credentials,
- artifact repository,
- production

erişimi sağlayabilir.

### Pipeline Access Security

CI/CD platformlarında kullanıcı ve service account yetkileri minimum privilege prensibine göre yönetilmelidir.

### Pipeline Secret Security

Pipeline içerisinde kullanılan;

- deployment credential,
- cloud token,
- registry password,
- API key

gibi bilgilerin güvenli secret management sistemlerinde tutulması gerekir.

### Build Environment Security

Build işlemlerinin gerçekleştirildiği runner veya build server'lar kritik güvenlik bileşenleridir.

Bu sistemler;

- izole,
- güncel,
- minimum yetkili,
- monitored

şekilde çalıştırılmalıdır.

### Ephemeral Build Environment

Her build için geçici runner oluşturularak işlem tamamlandıktan sonra runner silinebilir.

Bu yaklaşım build ortamları arasında kalıcı veri veya credential bırakılması riskini azaltabilir.

### Build Integrity

Build sonucunda oluşturulan yazılım artifact'ının beklenen kaynak koddan üretildiğinin doğrulanması önemlidir.

Bu amaçla build provenance ve signing mekanizmaları değerlendirilebilir.

### Build Provenance

Build Provenance, artifact'ın;

- hangi source code'dan,
- hangi build sisteminde,
- hangi süreçle

oluşturulduğuna ilişkin doğrulanabilir bilgi sağlar.

### Artifact Security

Build sonucunda oluşan artifact;

- binary,
- library,
- package,
- container image

olabilir.

Bu artifact'ın üretildikten sonra değiştirilmemesi gerekir.

### Artifact Signing

Artifact signing ile yazılım paketinin bütünlüğü ve kaynağı doğrulanabilir.

Production deployment öncesinde imza kontrolü yapılabilir.

### Artifact Repository Security

Artifact repository'ler kurumun production yazılımlarını sakladığı kritik sistemlerdir.

Repository üzerinde;

- MFA,
- RBAC,
- encryption,
- immutable artifact,
- logging

kontrolleri uygulanabilir.

### Container Supply Chain Security

Container tabanlı uygulamalarda software supply chain container image seviyesine kadar devam eder.

Container image içerisinde yüzlerce package bulunabilir.

### Container Image Scanning

Container image'lar;

- OS vulnerability,
- library vulnerability,
- malware,
- secret,
- configuration

riskleri açısından taranabilir.

### Base Image Security

Developer ekipleri rastgele public base image kullanmamalıdır.

Kurum tarafından onaylanmış ve güncel base image'lar oluşturulabilir.

Örneğin:

#### SecureSys Approved Base Image

↓

#### Application Layer

↓

#### Security Scan

↓

#### Private Registry

### Minimal Container Image

Container içerisinde ihtiyaç duyulmayan package'ların kaldırılması saldırı yüzeyini azaltabilir.

Minimal image yaklaşımı bu nedenle önemlidir.

### Container Registry Security

Container image'ların private registry üzerinde saklanması supply chain güvenliğini artırabilir.

Registry içerisinde;

- vulnerability scanning,
- image signing,
- RBAC,
- retention,
- audit logging

uygulanabilir.

### Image Signing

Container image'ların imzalanması ve deployment sırasında imza doğrulaması yapılması mümkündür.

Bu sayede yalnızca kurum tarafından onaylanan image'ların production ortamında çalıştırılması sağlanabilir.

### Kubernetes Admission Control

Kubernetes cluster'a deploy edilecek container'lar admission policy üzerinden kontrol edilebilir.

Örneğin:

**Unsigned Image → Block**

**Critical Vulnerability → Block**

**Unknown Registry → Block**

politikaları oluşturulabilir.

### Policy as Code

Software Supply Chain Security politikaları kod olarak tanımlanabilir.

Örneğin:

**SBOM Yok → Release Yok**

**Critical CVE → Deployment Yok**

**Unsigned Artifact → Production Yok**

**Hardcoded Secret → Build Fail**

Bu yaklaşım güvenlik politikalarının otomatik uygulanmasını sağlar.

### Security Gate

CI/CD pipeline içerisinde security gate oluşturularak belirlenen risk seviyesinin üzerindeki build'lerin production'a geçmesi engellenebilir.

Örneğin:

**Critical → Block**

**High → Security Approval**

**Medium → Remediation Plan**

**Low → Monitor**

### SAST ve Software Supply Chain Security

SAST kurumun kendi geliştirdiği kaynak kodu analiz eder.

SCA ise third-party component'leri analiz eder.

Bu nedenle;

#### SAST + SCA

birlikte kullanılmalıdır.

### SAST, SCA ve SBOM

Modern application security yaklaşımında:

**SAST → First-Party Code**

**SCA → Third-Party Components**

**SBOM → Component Inventory**

olarak düşünülebilir.

### DAST ve Supply Chain Security

DAST çalışan uygulamanın güvenlik davranışını test eder.

Supply Chain Security kontrollerini tamamlayıcı bir katman olarak kullanılabilir.

### DevSecOps Entegrasyonu

Software Supply Chain Security kontrolleri DevSecOps pipeline içerisine entegre edilmelidir.

Örnek SecureSys pipeline:

#### Developer

↓

#### Git

↓

#### Secret Scan

↓

#### SAST

↓

#### SCA

↓

#### SBOM

↓

#### Build

↓

#### Artifact Signing

↓

#### Container Scan

↓

#### Security Gate

↓

#### Deployment

↓

#### Continuous Monitoring

### Software Supply Chain Security ve DevOps

Güvenlik kontrollerinin developer ekiplerinin hızını tamamen durdurmaması gerekir.

Bu nedenle kontroller mümkün olduğunca otomatik hale getirilmelidir.

### Software Supply Chain Security ve Platform Engineering

[Internal Developer Platform](/tr/hizmetler/platform-engineering-internal-developer-platform-idp) üzerinden supply chain kontrolleri tüm developer ekipleri için standart hale getirilebilir.

Örneğin Golden Path içerisinde;

- SAST,
- SCA,
- SBOM,
- image scanning,
- artifact signing

varsayılan olarak aktif olabilir.

### Golden Path Security

Platform Engineering kapsamında oluşturulan application template'leri güvenli pipeline ile birlikte sunulabilir.

Developer güvenlik araçlarını tek tek yapılandırmak zorunda kalmaz.

### Software Supply Chain ve Zero Trust

Yazılım tedarik zincirindeki hiçbir bileşen yalnızca network içerisinde bulunduğu için güvenilir kabul edilmemelidir.

Her;

- developer,
- build system,
- artifact,
- container,
- deployment

doğrulanmalıdır.

### Least Privilege

Build ve deployment hesaplarına yalnızca ihtiyaç duydukları yetkiler verilmelidir.

CI/CD hesabının tüm production altyapısına administrator erişimine sahip olması engellenmelidir.

### Software Supply Chain ve PAM

Kritik build ve deployment sistemlerindeki privileged hesaplar PAM ile yönetilebilir.

### Software Supply Chain ve SIEM

Software development altyapısındaki kritik olaylar [SIEM](/tr/hizmetler/siem-soar-guvenlik-hizmeti)'e aktarılabilir.

Örneğin;

- repository admin değişikliği,
- branch protection kaldırılması,
- pipeline modification,
- artifact deletion,
- registry login,
- failed authentication

olayları izlenebilir.

### Software Supply Chain ve SOC 7x24

SecureSys [SOC 7x24](/tr/hizmetler/soc-7x24-izleme-managed-soc-hizmeti) hizmeti development ve software supply chain sistemlerinden gelen kritik güvenlik olaylarını izleyebilir.

Bu sayede güvenlik yalnızca production ortamıyla sınırlı kalmaz.

### Supply Chain Incident Response

Software supply chain üzerinde saldırı tespit edildiğinde hızlı müdahale gerekir.

Örneğin zararlı package tespit edildiğinde;

- Etkilenen component belirlenir.
- SBOM repository sorgulanır.
- Etkilenen uygulamalar çıkarılır.
- Production exposure belirlenir.
- Package engellenir.
- Güvenli versiyon hazırlanır.
- Uygulamalar yeniden build edilir.
- Deployment gerçekleştirilir.

### SBOM ile Incident Response

SBOM özellikle kritik zero-day vulnerability durumlarında Incident Response sürecini hızlandırabilir.

Yeni vulnerability yayınlandığında yüzlerce uygulamanın manuel kontrol edilmesi yerine merkezi SBOM envanteri sorgulanabilir.

### Software Supply Chain Risk Assessment

SecureSys mevcut yazılım geliştirme ortamının Software Supply Chain Security Assessment çalışmasını gerçekleştirebilir.

Analizde;

- Git,
- dependency,
- package repository,
- CI/CD,
- build server,
- artifact repository,
- container registry,
- Kubernetes,
- secrets

incelenebilir.

### SBOM Readiness Assessment

Kurumun SBOM üretmeye hazır olup olmadığı değerlendirilebilir.

Çalışmada;

- application inventory,
- build systems,
- dependency managers,
- CI/CD,
- artifact systems

analiz edilir.

### Open Source Governance

Kurum içerisinde hangi open source bileşenlerin kullanılabileceğine ilişkin politika oluşturulabilir.

### License Compliance

Open source package'lar yalnızca güvenlik açısından değil lisans açısından da değerlendirilmelidir.

SCA çözümleri package license bilgilerini analiz ederek potansiyel lisans risklerinin görünür hale getirilmesine yardımcı olabilir.

### End-of-Life Component Tespiti

Artık desteklenmeyen library veya framework'lerin kullanılması önemli güvenlik riski oluşturabilir.

SecureSys EOL component'lerin tespit edilmesini sağlayabilir.

### Legacy Dependency Management

Eski uygulamalarda güncellenemeyen dependency'ler bulunabilir.

Bu durumda risk;

- network isolation,
- WAF,
- monitoring,
- compensating control

mekanizmalarıyla azaltılabilir.

### Supplier SBOM Yönetimi

Kurum yalnızca kendi geliştirdiği yazılımlar için değil, dışarıdan satın aldığı yazılımlar için de SBOM talep edebilir.

Vendor tarafından sağlanan SBOM merkezi olarak saklanabilir.

### Third-Party SBOM Analysis

Yazılım üreticisinden alınan SBOM SecureSys tarafından analiz edilerek;

- vulnerable component,
- outdated package,
- EOL component,
- dependency risk

tespit edilebilir.

### Vendor Software Risk Assessment

Yeni bir yazılım satın alınmadan önce üreticinin;

- secure development,
- SBOM,
- vulnerability management,
- patch process,
- disclosure process

kabiliyetleri değerlendirilebilir.

### Software Procurement Security

Software Supply Chain Security satın alma süreçlerine kadar genişletilebilir.

Teknik şartnamelerde;

- SBOM teslimi,
- vulnerability remediation,
- secure development,
- patch SLA

gereksinimleri tanımlanabilir.

### SBOM ve Kamu Yazılım Projeleri

Kamu kurumlarına geliştirilen kritik yazılımlarda kullanılan third-party bileşenlerin görünürlüğü önemlidir.

SBOM yaklaşımı kurumun teslim aldığı yazılımın hangi bileşenlerden oluştuğunu kayıt altına almasına yardımcı olabilir.

### SBOM ve Kritik Altyapılar

Enerji, finans, savunma, telekom ve diğer kritik altyapılarda software component visibility operasyonel siber dayanıklılık açısından önem taşır.

### NIST SSDF ve Software Supply Chain Security

NIST Secure Software Development Framework güvenli yazılım geliştirme süreçlerinde yazılımın ve bileşenlerin korunması, güvenli yazılım üretimi ve vulnerability'lere müdahale edilmesi gibi alanları ele alır.

Software Supply Chain Security süreçleri Secure SDLC yaklaşımının önemli parçalarından biri olarak değerlendirilebilir.

### OWASP ve Software Supply Chain Security

OWASP kaynakları dependency security, software component analysis ve DevSecOps güvenlik kontrollerinin oluşturulmasında kullanılabilir.

### SLSA Yaklaşımı

SLSA – Supply-chain Levels for Software Artifacts, software artifact'larının üretim zincirinin güvenilirliğini artırmaya yönelik bir framework'tür.

SLSA yaklaşımında;

- source integrity,
- build integrity,
- provenance,
- artifact integrity

gibi alanlar önemlidir.

### Build Provenance ve SLSA

Build provenance sayesinde bir artifact'ın hangi source code ve build sistemi kullanılarak oluşturulduğuna ilişkin doğrulanabilir bilgi üretilebilir.

Bu yaklaşım software supply chain saldırılarının azaltılmasına yardımcı olabilir.

### Secure Build Pipeline

SecureSys güvenli build pipeline mimarisinde;

- protected source,
- isolated runner,
- trusted dependency,
- SCA,
- SBOM,
- artifact signing,
- provenance

kontrollerini birlikte değerlendirebilir.

### Reproducible Builds

Uygun projelerde aynı kaynak koddan aynı build sonucunun elde edilebilmesi supply chain güvenilirliğini artırabilir.

### Immutable Artifact

Production'a alınan artifact'ın sonradan değiştirilmesinin engellenmesi gerekir.

Artifact repository üzerinde immutable release politikaları uygulanabilir.

### Production Artifact Verification

Deployment öncesinde;

- signature,
- hash,
- provenance,
- approved registry

kontrolleri gerçekleştirilebilir.

### AI Generated Code ve Supply Chain Security

AI coding assistant kullanımının artması software supply chain süreçlerini de etkilemektedir.

AI tarafından önerilen kod;

- bilinmeyen package,
- eski dependency,
- güvensiz library,
- yanlış package name

içerebilir.

Bu nedenle AI-generated code da aynı supply chain kontrollerinden geçirilmelidir.

### AI Dependency Risk

AI coding assistant tarafından önerilen dependency doğrudan projeye eklenmemelidir.

Dependency;

**AI Suggestion → Developer Review → SCA → Approval → Build**

sürecinden geçirilebilir.

### LLM Uygulamalarında Software Supply Chain

LLM ve [Generative AI](/tr/hizmetler/llm-generative-ai-cozumleri) uygulamaları klasik package'ların yanında;

- AI framework,
- model,
- embedding library,
- vector database client,
- agent framework

gibi yeni dependency türleri kullanabilir.

Bu bileşenlerin de envanterinin tutulması önemlidir.

### AI BOM Yaklaşımı

AI sistemlerinde klasik SBOM yaklaşımının ötesinde model, dataset ve AI component envanterlerinin yönetilmesi giderek önem kazanmaktadır.

Kurumsal AI governance süreçlerinde;

- model,
- model version,
- AI framework,
- dependency,
- data source

gibi bileşenlerin görünürlüğü sağlanabilir.

### ISO/IEC 42001 ve Software Supply Chain

AI sistemleri geliştiren kurumlarda kullanılan third-party AI component, model ve framework'lerin yönetilmesi AI governance yaklaşımının önemli parçalarından biridir.

Software Supply Chain Security süreçleri AI geliştirme yaşam döngüsünün teknik güvenlik katmanını güçlendirebilir.

### Software Supply Chain Security KPI'ları

Supply chain güvenlik olgunluğu ölçülebilir.

Örnek KPI'lar;

- SBOM coverage,
- applications with SCA,
- critical dependency count,
- remediation time,
- unsigned artifacts,
- unsupported packages,
- secret detection count

olarak belirlenebilir.

### SBOM Coverage

Kurum içerisindeki uygulamaların yüzde kaçında güncel SBOM bulunduğu ölçülebilir.

Örneğin:

#### SBOM Coverage: %85

hedefi belirlenebilir.

### Critical Dependency SLA

Critical vulnerability bulunan dependency'lerin belirlenen süre içerisinde remediation edilmesi için SLA oluşturulabilir.

### Supply Chain Security Dashboard

SecureSys merkezi dashboard üzerinde;

- uygulama sayısı,
- SBOM durumu,
- vulnerable components,
- critical CVE,
- outdated dependencies,
- unsigned artifacts

bilgilerini sunabilir.

### Yönetici Raporlaması

Üst yönetim için teknik dependency detayları yerine;

- kritik uygulama riski,
- SBOM coverage,
- kritik vulnerability,
- remediation performance,
- supply chain risk trend

gibi göstergeler raporlanabilir.

### Software Supply Chain Security as a Service

Kendi içerisinde Application Security veya Software Supply Chain Security ekibi bulunmayan kurumlar için süreç yönetilen hizmet olarak sunulabilir.

SecureSys **Software Supply Chain Security as a Service** kapsamında;

- SCA,
- SBOM,
- dependency monitoring,
- vulnerability prioritization,
- security reporting,
- remediation tracking

süreçlerini yönetebilir.

### Managed SBOM Hizmeti

SecureSys Managed SBOM hizmetiyle kurumun uygulamalarına ait SBOM'ların;

- oluşturulması,
- merkezi saklanması,
- güncellenmesi,
- vulnerability verileriyle ilişkilendirilmesi,
- raporlanması

sağlanabilir.

### Continuous Software Supply Chain Monitoring

Tek seferlik tarama yerine uygulamaların dependency envanteri sürekli izlenebilir.

Yeni vulnerability yayınlandığında etkilenen uygulamalar belirlenerek aksiyon oluşturulabilir.

### SecureSys Software Supply Chain Security Hizmet Süreci

#### \1. Yazılım Envanteri

Kurum içerisindeki uygulamalar belirlenir.

#### \2. Development Environment Analizi

Git, CI/CD, build ve repository sistemleri incelenir.

#### \3. Dependency Discovery

Uygulamaların kullandığı third-party component'ler belirlenir.

#### \4. SCA

Dependency vulnerability ve license analizleri gerçekleştirilir.

#### \5. SBOM

Uygulama bazlı Software Bill of Materials oluşturulur.

#### \6. CI/CD Entegrasyonu

SBOM ve SCA süreçleri pipeline içerisine alınır.

#### \7. Repository Security

Git, branch, secret ve access politikaları değerlendirilir.

#### \8. Build Security

Build runner ve credential güvenliği kontrol edilir.

#### \9. Artifact Security

Artifact signing ve integrity kontrolleri uygulanır.

#### \10. Container Security

Container image ve registry güvenliği değerlendirilir.

#### \11. Continuous Monitoring

Yeni vulnerability'ler SBOM ve dependency envanteriyle eşleştirilir.

#### \12. Raporlama ve İyileştirme

Riskler önceliklendirilerek remediation süreçleri takip edilir.

### Neden SecureSys Software Supply Chain Security?

Modern uygulama güvenliği yalnızca [kaynak kod analizi](/tr/hizmetler/kaynak-kod-analizi-sast-hizmeti) veya penetration testinden oluşmaz.

Bir uygulama güvenli kodla geliştirilmiş olsa bile kullandığı third-party dependency, CI/CD pipeline veya container image nedeniyle risk altında olabilir.

Bu nedenle SecureSys;

**Source Code + Dependency + SBOM + CI/CD + Build + Artifact + Container + Runtime**

zincirini birlikte değerlendirir.

Software Supply Chain Security yaklaşımımız;

**Know What You Use → Verify What You Build → Trust What You Deploy → Monitor What You Run**

prensibine dayanır.

### Sık Sorulan Sorular

#### Software Supply Chain Security nedir?

Yazılımın geliştirilmesinden production'a alınmasına kadar kullanılan kaynak kod, dependency, build, artifact, container ve deployment bileşenlerinin güvenliğinin sağlanmasıdır.

#### SBOM nedir?

Software Bill of Materials, bir yazılım içerisinde kullanılan component ve dependency'lerin yapılandırılmış envanteridir.

#### SCA nedir?

Software Composition Analysis, uygulamalardaki open source ve third-party dependency'leri güvenlik ve lisans riskleri açısından analiz eder.

#### SBOM ile SCA aynı şey midir?

Hayır. SCA bileşenleri analiz ederken SBOM yazılım bileşenlerinin yapılandırılmış envanterini oluşturur. Birlikte kullanılmaları daha güçlü görünürlük sağlar.

#### SBOM her release için oluşturulmalı mı?

Dinamik geliştirme ortamlarında her build veya release için güncel SBOM oluşturulması daha doğru bir yaklaşım olabilir.

#### SBOM CVE tespit edebilir mi?

SBOM kendi başına vulnerability scanner değildir. Ancak SBOM içerisindeki component'ler vulnerability intelligence verileriyle eşleştirilerek etkilenen uygulamalar belirlenebilir.

#### Container image için SBOM oluşturulabilir mi?

Evet. Container image içerisindeki package ve component'ler analiz edilerek SBOM üretilebilir.

#### SBOM CI/CD pipeline'a entegre edilebilir mi?

Evet. Her build sırasında otomatik SBOM üretimi gerçekleştirilebilir.

#### Software Supply Chain Security DevSecOps'un parçası mıdır?

Evet. SCA, SBOM, secret scanning, artifact security ve container security modern DevSecOps süreçlerinin önemli parçalarıdır.

#### Managed SBOM hizmeti alınabilir mi?

Evet. SBOM oluşturma, güncelleme, vulnerability monitoring ve raporlama süreçleri yönetilen hizmet modeliyle yürütülebilir.

### Yazılım Tedarik Zincirinizi SecureSys ile Görünür ve Güvenli Hale Getirin

Bir yazılımın güvenliği yalnızca geliştiricinizin yazdığı kodun güvenliği değildir.

Uygulamanızın kullandığı yüzlerce open source dependency, build sistemi, CI/CD pipeline, container image ve artifact da aynı güvenlik zincirinin parçasıdır.

SecureSys Software Supply Chain Security & SBOM Hizmetleri ile;

**Source Code → SCA → SBOM → Dependency Security → Secure Build → Artifact Signing → Container Security → Deployment → Continuous Monitoring**

süreçlerini merkezi bir güvenlik modeli altında yönetebilirsiniz.

Kritik bir vulnerability yayınlandığında günlerce **“Bu bileşeni hangi uygulamalarımız kullanıyor?”** sorusunun cevabını aramak yerine güncel SBOM ve yazılım envanteriniz üzerinden etkilenen sistemleri hızlı şekilde belirleyebilirsiniz.

**Yazılım tedarik zinciri risklerinizi analiz ettirin, SBOM altyapınızı oluşturun ve kullandığınız her yazılım bileşenini görünür hale getirin.**