1. Security Automation Data
supply chain security lost in a maze of XML and
JSON
Marcus Meissner
Projectmanager Security / Distinguished Engineer
meissner@suse.de

2. 2
Agenda
●
Introduction
●
The SCAP family
●
Newcomers
●
New things and changes past Solarwinds and log4shell

3. 5
Introduction

4. 6
Introduction – Why?
• Amount of computers growing
– Hard to even enumerate the ones at home
• Laptop, tablet, phones, tv, car, cameras, toys, home automation, etc.
– Enterprise setting
• Baremetal / Edge
• VMs
• Containers
• Public Cloud instances
• Amount of care needed differs, depends:
– How much access / control do we have
– Managed by us or by others … or no one
– Internet connected / Importance / relevance

5. 7
Inventory
Without Inventory we are blind
• Hardware (not in scope here)
• Operating System
• Software installed
• Configurations and Settings…
• Recursion into Vms or Containers

6. 8
Operating System / Software
Interesting pieces about software
• Lifecycle
• Affectedness by security issues
• Recursion for embedded sources
• Recursion for static builds (e.g. builds with go, rust etc)
• Dependency on build environment
• How to proof or verify this is correct
Manual work impossible, automate everything!

7. 9
The SCAP family
Secure Content Automation Protocol

8. 10
Secure Content Automation Protocol - SCAP
One of the early comers, defined by the US NIST
Encompasses formats:
• OVAL, XCCDF, OCIL, ARF, CCE, CPE, CVE, CVSS, CCSS
Standard Version: 1.3
Supporting tool: openscap

9. 11
CVE – Common Vulnerability & Exposures
Goal: A dictionary entry identifying a specific security vulnerability.
CVE-Year-NR
• Year is the time the security issue was identified.
• NR is allocated out of non-linear blocks (no specific meaning)
Assigned by CNAs (Candidate Naming Authorities).
When use, make sure you copy and paste only to avoid typos!

10. 12
CVSS - Common Vulnerability Scoring System
Goal: Trying to classify security vulnerabilities into schemes and
numbers.
• Base Vector, Temporal Vector, Environmental Vector
• Sample Base Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Score: 0.0-10.0 (above is 7.8)
Currently at revision 3.1, revision 4 being worked on.
Facts:
• As security issues are programmatic, translation into a simple arithmetic vector is
hard
• Not all criteria map well
• There is a lot of human judgment involved, rating might vary

11. 13
CPE – Common Platform Enumeration
Goal: Specify operating systems and/or software in a defined way.
Standardized hierarchic tag format:
• cpe : ID : vendor : product : version : minor version …
Idea is that you can synthesize it yourself, but there is a global
dictionary.
Examples used by SUSE:
• cpe:/o:suse:sles:15:sp4 ( in /etc/os-release )
• cpe:/o:opensuse:tumbleweed:20230510
• cpe:2.3:a:samba:samba:*:*:*:*:*:*:*:* (in some other security data)
Not very widespread, also replaced by other formats like purl.

12. 14
CCE – Common Configuration Enumeration
Goal: Dictionary to reference configuration issues
IDs handed out by NIST to vendors.
Used in hardening automation.

13. 15
CCSS – Common Configuration Scoring System
Goal: Measure severity of configuration mismatches
So /etc/shadow world-readable is higher than “telnet client” installed.
Used in the hardening tooling.

14. 16
OCIL – Open Checklist Interactive Language
Goal: Allow automation of manual security checklist processing
Going over the checklist is automated.
The tests and remediations for each check are manual actions.
Not used at SUSE.

15. 17
OVAL – Open Vulnerability Assessment
Language
Goal: Detection of system conditions
Uses: CVE, CPE, CVSS ids
Checks for:
• Presence, permission, ownership of files
• Content of files (line based)
• RPM – presence , name , version , release based detection
• More
Definitions that describe vulnerabilities, patches, inventory
• Metadata like description, references, cpe ids, cvss scores
• Link to checks via a tree of criteria that can be combined with OR/AND logic

16. 18
OVAL – Open Vulnerability Assessment
Language
Example available logic:
System is affected by a CVE when:
• product X OR product Y is installed
• AND
– Package P1 is less than version1-release1, OR
– Package P2 is less than version2-release2
/etc/shadow has insecure permissions:
• File permission of /etc/shadow is not MODE 640, OR
• File ownership of /etc/shadow is not USER root, OR
• Group ownership of /etc/shadow is not GROUP shadow

17. 19
OVAL – Open Vulnerability Assessment
Language
SUSE usage:
Provide security vulnerability data
• Indexed by CVE
• Indexed by patches
• For released updates, but also for “not affected” or “affected” issues, or “in QA”.
• Sample call: oscap oval eval suse.linux.enterprise.15.xml
Detection logic for XCCDF in scap-security-guide

18. 20
XCCDF – eXtensible Configuration and Definition
Format
Goal: provide flexible security hardening automation
References: OVAL, CCE, CCSS
Invented to automate security hardening with STIG as example
• High level Profiles, specify rules to enable
• Rules
– Metadata: description, identifiers (CCE, etc.), priority, rationales
– Detection (references to OVAL definitions or also detection shell scripts)
– Remediation (can be manual, shellscript, ansible … )

19. 21
SCAP - ComplianceAsCode
XCCDF and OVAL are heavily nested XML, manual editing hard.
Red Hat and others invented a generator framework called
“ComplianceAsCode” which can generate various formats out its
tree.
SUSE is developing their own SCAP profiles together with the
ComplianceAsCode community.
Shipped in “scap-security-guide” package.

20. 22
SCAP – scap-security-guide SUSE usage
SUSE provides SCAP implementations for
• DISA STIG
• PCI-DSS
• HIPAA
• CIS
• ANSSI-BP-028
• SUSE specific hardening for public cloud images

21. 23
The newcomers

22. 24
CVRF – Common Vulnerability Reporting Format
Goal: machine readable advisories and vulnerability exchange
Version: 1.2 (obsoleted by CSAF)
Format: XML
References: CVE, CVSS, CPE
Invented to automate security vulnerability exchange
• Express security advisories in standard format
• Automated detection of vulnerabilities
• Import to ticket systems
No logic like OVAL, but a hierarchical software component tree

23. 25
CVRF – Common Vulnerability Reporting Format
SUSE Usage
• CVRF by advisory id
– Can report fixed security issues by the advisory
• CVRF by CVE
– Can report: affected, not affected, released, in qa
Disadvantage: lots of files (1 file per patch or CVE)

24. 26
CSAF – Common Security Advisory Format
Goal: machine readable advisories and vulnerability exchange
Version: 2.0 (replaces CVRF)
Format: JSON
References: CVE, CVSS, CPE
Automate security vulnerability exchange
• Express security advisories in standard format
• Automated detection of vulnerabilities
• Import to ticket systems
Again a hierarchical software component tree

25. 27
CSAF – Common Security Advisory Format
SUSE Usage
• CSAF by advisory id
– Can report fixed security issues by the advisory
• CSAF by CVE
– Can report: affected, not affected, released, in qa
Disadvantage: lots of files (1 file per patch or CVE)

26. 28
New things and changes in recent years

27. 29
What changed?
• Software becoming more interlinked and more complex
• Attacks becoming more direct / more impactful
– Not just smuggling out information
– Destructive / distributed denial of service
– Ransom – whole companies
– Make money out of crypto mining
• Exploits targeting the software supply chain to be more widespread
Solarwinds and log4shell as key triggers

28. 30
What changed?
• People and Governments identified software supply chain security as
having gaps and reacted on it
• US government issued Executive Order 14028 May 12th
2021
• Europe is working on a cyber resilience act
Gaps covered:
• Software Bill of Materials (SBOM)
• Attestation or provenance of build (SLSA attestation)
• Cryptographic assurances

29. 31
SBOM – Software Bill of Materials
Goal: Clear inventory of Software Deliveries
Wanted: structured export of
• Producers and redistributors/suppliers
• Exact versions, licenses
• Software embedded in other software
• Cryptographic hashes / verification
Three main file formats currently:
• SPDX 2.0
• CycloneDX
• SWID

30. 32
SBOM – SUSE Deliveries
Formats:
• SPDX 2.0 (prefered by the LinuxFoundation)
• CycloneDX (widespread use in the container ecosystem)
Delivered for:
• ISO: SPDX 2.0 and CycloneDX
• Containers: SPDX 2.0 embedded in SLSA attestation

31. 33
SBOM – SPDX 2.0
Originally SPDX was for standardized license tracking.
Enhanced to support full SBOM for 2.0 version.
Fileformats: various: plaintext, XML, JSON, …
SUSE uses JSON variant.

32. 34
SBOM – CycloneDX
Fileformats: XML or JSON
CycloneDX can not just cover SBOM, but also
• Saas BOM
• HW BOM
• Operations BOM
• Vulnerability Disclosure Reports (VDR)
• Vulnerability Exploitability eXchange (VEX)

33. 35
VEX – Vulnerability Exploitability eXchange
Goal: Declare affected or not affected for security issues
Existing:
• CVRF: CVE indexed format would qualify
• CSAF (has a VEX profile): ready
Others:
• CycloneDX
• OpenVEX project (picked up by OSSF)

34. 36
VDR – Vulnerability Disclosure Report
Goal: Declare affected or not affected of a product
Supplements an SBOM.
Currently not clear what is needed here.

35. 37
Attestation and Provenance
Goal: define how software was built into binary
Why: defined description how a binary was built, reproducibility
Primary contender:
• SLSA attestation “in-toto”

36. 38
SLSA In-toto provenance
Specify every package this target was built with
• RPMs listed with URLs and SHA2 hashes (rpms provided externally)
• Buildconfiguration linked (OBS projectconfig) with SHA2
• Sources within package linked and referenced with SHA2
Provenance provided parallel to built RPM, ISO, Container.
Challenges:
• Rolling releases (how many Terabyte diskspace do you own?)
• Bootstrapping (where do you start?)

37. 80
Landing page: https://www.suse.com/security/
E-Mail: security@suse.de
Questions?

38. 81

39. 82

41. 84
Internal Use Slides

42. Presentation Title(36pt)
Subhead or Second Line (20pt)
Presenter Name (14pt)
Title
Company/Email
For Internal Use Only