Updated June 2026 | Category: Software Security / Supply Chain / Code Signing / Publisher Security / SDLC | Reading time: 12 min
Software security is the set of practices, processes, and technical controls that protect software from being exploited, compromised, or used against the interests of its users and publishers. It encompasses how software is written, how it is built, how it reaches users, and how it behaves at runtime.
For software publishers (developers and organizations that produce and distribute software), security has a specific meaning beyond just avoiding vulnerabilities. It includes protecting the integrity of the software you ship: ensuring that what users install is exactly what you built, that your publisher identity is verified and cannot be impersonated, and that your distribution infrastructure cannot be used to deliver malicious software under your name.
This article covers software security from the publisher’s perspective: what it involves at each stage of the software lifecycle, why it has become critically important in the current threat environment, and where code signing fits in a complete publisher security posture.
Software Security Across the Software Lifecycle
Software security is not a single control applied at one point. It spans the entire lifecycle from writing code through deployment and operation. Vulnerabilities or weaknesses at any stage can undermine controls at every other stage.
Stage 1: Secure development (the code itself)
Secure development addresses vulnerabilities in the software’s own logic: memory safety issues that enable buffer overflow attacks, input validation failures that enable injection attacks, insecure use of cryptography, hardcoded credentials, and improper access control. These vulnerabilities exist within the software itself and can be exploited by any user of the software, regardless of how it was distributed.
The OWASP Top 10 (for web applications) and the SANS/CWE Top 25 Most Dangerous Software Weaknesses provide catalogues of the most common and impactful vulnerability categories. Static application security testing (SAST), dynamic analysis (DAST), and software composition analysis (SCA) are the tool categories that developers use to find vulnerabilities before release.
Secure development is necessary but not sufficient for publisher security. A software publisher can ship perfectly secure code and still have their users compromised if the distribution process is attacked.
Stage 2: Supply chain security (what you build with)
Modern software is built from components: open-source libraries, third-party SDKs, build tools, CI/CD platform integrations, and developer workstations. The supply chain encompasses all of these. An attacker who compromises any component in the supply chain can insert malicious code into software that the legitimate developer then builds and ships with their trusted signature.
The SolarWinds attack in 2020 is the defining supply chain security incident of recent years. Attackers compromised the build environment of SolarWinds, a network management software vendor. Malicious code was inserted into the build process and incorporated into signed software updates delivered to approximately 18,000 customers, including US government agencies. The software was legitimately signed by SolarWinds, distributed through official channels, and passed all conventional security checks. The attack succeeded because it occurred before signing, at the build layer.
Supply chain security controls include: reproducible builds (verifying that the same source code always produces the same binary), software bills of materials (SBOM, documenting all components in a software package), supply chain integrity frameworks like SLSA (Supply Chain Levels for Software Artifacts), and dependency auditing to detect compromised or malicious open-source packages.
Stage 3: Distribution integrity (what users receive)
Distribution integrity is the assurance that software reaching users is identical to what the publisher produced and released. Between a publisher’s release and a user’s installation, software passes through download servers, CDNs, package repositories, and potentially third-party distribution channels. Each handoff point is a potential substitution or tampering opportunity.
This is the stage that code signing directly addresses. An Authenticode signature on a Windows executable, a GPG signature on a Linux package, an Apple Developer ID signature on a macOS application: these are publisher assertions that this specific file was produced by this verified publisher. Any modification to the file after signing invalidates the signature. Any attempt to distribute a different file under the same publisher name fails because the signature cannot be forged without the publisher’s private key.
Distribution integrity is distinct from supply chain integrity: supply chain attacks happen before signing; distribution attacks happen after. Code signing addresses distribution integrity. SLSA and reproducible builds address supply chain integrity. Both are necessary; neither substitutes for the other.
Stage 4: Runtime security (what the software does)
Runtime security concerns what a software application does when executing: what permissions it requests, how it handles sensitive data, whether it follows the principle of least privilege, how it communicates on the network, and how it behaves when processing untrusted input. Software that requests more system access than its functionality requires creates unnecessary attack surface.
For Windows applications, runtime security involves appropriate use of UAC elevation (requesting administrator privileges only when necessary), data execution prevention (DEP) and address space layout randomization (ASLR) compatibility, and secure communication practices (TLS for all network connections, certificate validation).
Why Software Security Matters More Than Ever
Software is infrastructure
Software is embedded in every critical system: healthcare, financial services, energy infrastructure, transportation, and government operations. Software vulnerabilities that might have been minor nuisances when software was primarily on personal computers can now affect life-safety systems and national security. The consequences of insecure software have scaled with software’s role in the world.
Regulatory and legal requirements
Software security is increasingly a legal and regulatory obligation rather than just a best practice. The SEC now requires publicly traded companies in the US to disclose material cybersecurity incidents and annually report their cybersecurity risk management processes. The EU’s Cyber Resilience Act (entering force in stages through 2027) imposes security requirements on products with digital elements sold in Europe, including mandatory vulnerability disclosure and security update obligations. The US Cybersecurity and Infrastructure Security Agency (CISA) has published software security guidance that has become de facto compliance standards for government contractors and their software suppliers.
For software publishers, these regulatory developments mean that software security decisions have legal liability implications. A company that ships software with known vulnerabilities, fails to disclose a breach, or neglects basic security hygiene may face regulatory enforcement, civil liability, or loss of government contracts.
Supply chain attacks have become the preferred attack vector
Attackers have shifted toward supply chain attacks because they are more efficient. Compromising a widely-used software component or build environment once can affect thousands of downstream customers. The effort-to-impact ratio favors attackers targeting the supply chain over attackers targeting individual end systems.
The XZ Utils backdoor discovered in March 2024 illustrated the patience involved in modern supply chain attacks: a threat actor spent approximately two years building trust and reputation as a legitimate contributor to the XZ Utils compression library before inserting a backdoor into the build process. The backdoor was caught by a Microsoft engineer noticing unexpected SSH authentication behavior in a benchmarking test. It had been present in release candidates before detection.
Trust is the product
For software publishers, trust is not just a nice-to-have: it is a core product attribute. Users who cannot trust that the software they install is safe, authentic, and does what it claims will not install it. Enterprise customers who cannot verify software integrity will not deploy it. The competitive and commercial consequences of a trust failure can be permanent.
A software publisher whose signing certificate is compromised and used to sign malware, or whose update server is hijacked to deliver malicious updates, faces reputational damage that may not be recoverable. Users associate the attack with the publisher’s name because the publisher’s name was on the signature.
Where Code Signing Fits in Software Security
Code signing is a publisher security control focused on distribution integrity and publisher identity. It is not a substitute for secure development (it does not fix vulnerabilities in code), and it is not a substitute for supply chain security (it does not protect against attacks that occur before signing). Code signing’s specific role is to provide a cryptographic commitment: this file was produced by this publisher and has not been modified since.
| Security concern | Code signing addresses it? | What addresses it |
| Software vulnerabilities in the published code | No | Secure development practices, SAST/DAST, security reviews, patching |
| Compromised open-source dependency | No | Software composition analysis (SCA), dependency auditing, SBOM |
| Build process compromise (like SolarWinds) | No (code is signed after compromise) | Reproducible builds, SLSA, build environment integrity controls |
| File tampering in transit or on download server | Yes | Authenticode/code signing signatures verify file integrity |
| Impersonation of publisher identity | Yes | OV/EV certificates verify organizational identity before issuance |
| Malicious redistribution under publisher’s name | Yes | Signature cannot be forged without publisher’s private key |
| User trusting malware as legitimate software | Partially | Code signing shows publisher name; user still must verify name matches expected publisher |
Code signing provides the last line of defense in distribution integrity: the guarantee that survives even a fully compromised download server, CDN, or distribution channel. If every other distribution control fails but the publisher’s private key is protected, the code signature remains unforgeable and users can verify authenticity. This is why key security (hardware tokens, cloud HSMs, strict access controls) is the most important operational aspect of code signing security.
Building a Publisher Security Posture: Where to Start
For a software publisher building or improving their security posture, a practical starting sequence:
- Sign your software: Obtain an OV code signing certificate from a trusted CA and sign all distributed executables with a timestamp. This is the immediate, high-impact control for distribution integrity. It addresses impersonation and distribution tampering.
- Secure your signing infrastructure: Protect the private key with hardware storage (physical USB token or cloud HSM). Losing or exposing the private key undermines all the trust built by the certificate. Establish a formal process for certificate renewal with advance calendar reminders.
- Audit your dependencies: Run software composition analysis against your codebase to identify known-vulnerable dependencies. Establish a process for dependency updates when CVEs are disclosed against packages you use.
- Secure your build environment: Treat your CI/CD pipeline as a critical security boundary. Limit access to build secrets and signing credentials. Log and monitor build activity. Consider build attestation and SBOM generation to provide downstream consumers with component visibility.
- Establish a vulnerability response process: Have a documented process for receiving, assessing, and responding to vulnerability reports. A security contact on your website and a policy (or adopt an existing one such as coordinated vulnerability disclosure guidelines from CISA) prepares you to respond appropriately when issues are found.
- Understand your regulatory environment: If you sell to enterprise customers, government, or across jurisdictions, identify which software security regulations apply to you. The EU Cyber Resilience Act, US NIST frameworks, and sector-specific requirements (healthcare, financial services) may create specific obligations.
Frequently Asked Questions
What is the difference between software security and cybersecurity?
Cybersecurity is the broader field covering protection of all digital systems, networks, and data. Software security is a component of cybersecurity focused specifically on the security of software: how it is built, distributed, and operated. A cybersecurity program covers network security, endpoint security, access management, incident response, and many other domains. Software security is specifically about the software artifact itself: its code, its supply chain, and its distribution.
Does code signing make software secure?
Code signing makes software’s origin and integrity verifiable, which is a security property, but it does not make insecure code secure. A signed application with SQL injection vulnerabilities is still vulnerable to SQL injection. A signed application with insecure network communication can still be intercepted. Code signing verifies that the software came from who it claims and has not been modified, but does not evaluate or improve the security of the software’s own logic. Security requires both: code that is written securely AND distribution integrity controls like code signing to ensure that secure code reaches users unmodified.
What is supply chain security in software?
Software supply chain security is the set of practices protecting the integrity of the components, tools, and processes used to build software. A software supply chain includes all open-source and third-party libraries the software depends on, the build tooling and CI/CD pipeline, developer workstations and credentials, and any third-party services integrated into the build process. Compromising any supply chain component can allow an attacker to insert malicious code that is then built into legitimate software and signed by the legitimate publisher. The SolarWinds and XZ Utils attacks are documented examples. Supply chain security controls include SBOM generation, dependency auditing, reproducible builds, and build environment access controls.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.