In recent years the amount of vulnerabilities and also the amount of systems, installations or containers a single sysadmin has to oversee has grown beyond any human capable measures. The best help here is more automation in various places, which needs to be driven by automation consumable data. We will look at two primary areas, the automation data provided by SUSE for security fixes and also very fresh the inventory data, or "Software Bill of Materials (SBOM)". The talk will go over various formats, what SUSE offers and their purposes and also give some future look out on more improved or even more automation data formats.

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