In this lesson,
we will learn about Integrity Use Cases.
Use cases related to integrity involve maintaining
the accuracy and trustworthiness of data,
or software to ensure its functionality and security.
Specific use cases include knowing the software provenance,
as well as software and code integrity.
Software provenance ensures the origin and history
of software components are known and secure.
Software and code integrity ensures that software
and code have not been altered from their original
and trusted state.
Let's learn more about software provenance
as well as software and code integrity.
First, we have software provenance.
Software provenance is all about understanding the origin
and history of software components used
within an organization.
Software provenance answers critical questions like,
where did this software come from and can I trust it?
This involves knowing exactly
who developed each piece of software, where it originated,
and how it has changed over time.
In an enterprise setting, software provenance
is often managed through version control systems
such as Git.
Git tracks every change made to the code base.
Recording details like what changes were made,
when were they made, and by whom.
This creates a comprehensive history
of the software's development,
allowing organizations to audit
and trace the entire evolution of their code.
Version control not only helps with tracking changes,
but also provides a mechanism to roll back
to previous trusted versions if any issues are detected.
Another critical component of managing software provenance
is the use of a software bill of materials (SBOM).
An SBOM is like a detailed recipe
that lists all the ingredients, components, libraries,
and dependencies that make up a software application.
An SBOM provides a transparent view
of what is inside the software, including third party
and open source components.
Next, Software Composition Analysis (SCA) Solutions
such as Snyk, Black Duck, or WhiteSource can be used
to scan Software Bills of Material to verify
that all components are sourced from trusted origins.
In this way, Software Composition Analysis tools can check
for vulnerabilities, licensing issues,
and signs of tampering.
For instance, Software Composition Analysis
or SCA tools can detect if a seemingly legitimate component
has been swapped with a compromised version.
SCA tools do this by scanning the code base,
and analyzing all components and dependencies used
in the application.
They identify each component including its version,
and compare it against a known database
of trusted components and security vulnerabilities.
By maintaining a detailed inventory of components,
SSCA tools can flag any discrepancies,
such as an unexpected version or a component sourced
from an unverified repository.
SCA tools also check the integrity of each component
by compelling cryptographic hashes against those
from known sources.
If the hash doesn't match,
it indicates that the component may have been tampered with
or replaced with a compromised version.
This process helps ensure
that only the correct secure versions of components
are used, protecting the software
from potential security threats introduced
through the supply chain.
By using these tools and practices,
enterprises maintain comprehensive records
of their software's development and composition.
This level of transparency allows organizations
to trace each component back to its source,
verify its integrity, and ensure that the software complies
with security standards.
In this way, provenance tracking helps guard
against supply chain attacks
where malicious actors try to insert compromised components
during the software development process.
Second, we have software code and integrity.
Software code and integrity are used for ensuring
that software remains secure, reliable,
and unchanged from its original trusted state.
This is particularly important in enterprise environments
where unauthorized changes can introduce vulnerabilities
or malicious code.
To maintain integrity, organizations use a combination
of cryptographic hashes and code signing.
Cryptographic hashes create a unique digital footprint
for each version of the code.
These hashes are stored securely and are recalculated,
and compared to the original hash each time the code
is accessed, modified, or deployed.
If the hashes match,
it confirms that the code has not been altered.
This helps detect unauthorized modifications
in code very early.
Next, code signing adds another layer of security
by allowing developers to sign their code
with a digital certificate issued
by a trusted certificate authority.
The code itself is often not encrypted,
instead a hash of the code is created and the hash
is encrypted with the developer's private key.
Forming a digital signature attached to the code.
During verification, the system uses
the developer's public key to decrypt the signature,
which was encrypted with the developer's private key
revealing the original hash.
The system then generates a new hash on its own
from the downloaded code and compares it
to the decrypted hash signed by the developer's private key.
If they match, it confirms the code is authentic
and unaltered.
If not, that code is flagged as untrusted.
For example, when a developer signs their code,
a hash of their code is created and encrypted
with their private key.
This signature is then distributed with the code
when someone downloads it.
Upon download, the user system checks the certificate,
decrypts the signature using the developer's public key
and compares the hashes to ensure
the code has not been tampered with.
This process is automated in the continuous integration
and continuous deployment pipelines using tools like Jenkins
or GitLab CL, where security plugins verify signatures
and check hashes for every code change.
By integrating these types of checks,
enterprises can effectively protect their software
against unauthorized modifications,
ensuring that the software remains
in its original secure state.
So remember, software provenance tracks the origin
and history of software components,
helping organizations verify where their software came from
and whether it can be trusted.
Enterprises use Version Control Systems
and Software Bills of Material to maintain detailed records
of all changes and components used.
Next, Software Composition Analysis tools can scan
these records to ensure that components
are from trusted sources and have not been compromised.
Then software and code integrity ensures
that software remains secure and unchanged
through cryptographic hashes and code signing.
This also confirms that the code has not been altered.
These practices work together as integrity use cases
to protect software from unauthorized modifications
and maintain its security and reliablity.