In this episode of the podcast (#216), sponsored by Digicert, we talk with Brian Trzupek, Digicert’s Vice President of Product, about the growing urgency of securing software supply chains, and how digital code signing can help prevent compromises like the recent hack of the firm SolarWinds.


We spend a lot of time talking about software supply chain security these days? But what does that mean. At the 10,000 foot level it means “don’t be the next Solar Winds” – don’t let a nation state actor infiltrate your build process and insert a backdoor that gets distributed to thousands of customers – including technology firms three letter government agencies. 

OK. Sure. But speaking practically, what are we talking about when we talk about securing the software supply chain? Well, for one thing: we’re talking about securing the software code itself. We’re talking about taking steps to insure that what is written by our  developers is actually what goes into a build and then gets distributed to users.

Digital code signing – using digital certificates to sign submitted code – is one way to do that. And use of code signing is on the rise. But is that alone enough?  In this episode of the podcast, we’re joined by Brian Trzupek the SVP of Product at Digicert to talk about the growing role of digital code signing in preventing supply chain compromises and providing an audit trail for developed code.

Brian is the author of this recent Executive Insight on Security Ledger where he notes that code signing certificates are a highly effective way to ensure that software is not compromised -but only as effective as the strategy and best practices that support it. When poorly implemented, Brian notes, code signing loses its effectiveness in mitigating risk for software publishers and users.

In this conversation we talk about the changes to tooling, process and staff that DEVOPS organizations need to embrace to shore up the security of their software supply chain. 

“It boils down to do you have something in place to ensure code quality, fix vulnerabilities and make sure that code isn’t incurring tech debt,” Brian says. Ensuring those things involves both process, new products and tools as well as the right mix of staff and talent to assess new code for security issues. 

One idea that is gaining currency within DEVOPS organizations is “quorum based deployment” in which multiple staff members review and sign off on important code changes before they are deployed. Check out our full conversation using the player (above) or download the MP3 using the button below.


As always,  you can check our full conversation in our latest Security Ledger podcast at Blubrry. You can also listen to it on iTunes and check us out on SoundCloudStitcherRadio Public and more. Also: if you enjoy this podcast, consider signing up to receive it in your email. Just point your web browser to securityledger.com/subscribe to get notified whenever a new podcast is posted.

The recent SolarWinds attack highlights an Achilles heel for enterprises: software updates for critical enterprise applications. Digital signing of code is one solution, but organizations need to modernize their code signing processes to prioritize security and integrity and align with DevOps best practices, writes Brian Trzupek the Senior Vice President of Products at DigiCert in this thought leadership article.


Even in today’s security-charged world, the SolarWinds breach was a wakeup call for cybersecurity professionals. It was distinguished by its sophistication and the fact that it was carried out as part of legitimate software updates. The incident was quickly all over the news and has brought renewed focus on need for secure DevOps.

Automating your way out of PKI chaos.”

Code Signing Alone Is Not Enough

The security incident at SolarWinds was especially unsettling because could easily happen at any large software organization that delivers regular updates. Code signing certificates are a highly effective way to ensure that software is not compromised. However, it is only as effective as the strategy and best practices behind it. When poorly implemented, code signing loses its effectiveness in mitigating risk for software publishers and users. Issues often include:

  • Using the same signing key to sign all files, across multiple product lines and businesses
  • Lack of mechanisms in place to control who can sign specific files
  • Insufficient reporting capabilities for insights into who signed what and when
  • Failure to sign code at every stage of development, as part of an overall security by design process
  • Lack of signing and verifying code from third parties
  • Poor processes for securing keys and updating them to new key size or algorithm requirements
  • Failure to test code integrity before signing
  • Inadequate visibility into where certificates are, and how they are managed

Common pitfalls might include using the same signing key to sign all files, across multiple product lines and businesses. Some organizations might have no mechanisms in place to control who can sign specific files. They may also lack reporting capabilities, which can provide insights into who signed what—and when.

[Read Brian’s piece Staying Secure Through 5G Migration.]

What have we learned from the SolarWinds attack? For organizations where DevOps is fundamental, applying best practices to signing processes is more essential than ever. According to some studies, more than half of IT security professionals are concerned about bad actors forging or stealing certificates to sign code—but fewer than a third enforce code signing policies on a consistent basis. It’s time for organizations to do better and enforce zero-trust
across all their systems, signing everything, at every stage after verifying it is secure.

Simplifying and standardizing

Traditional code signing processes can be complex and difficult to enforce. They are often based on storing keys on desktops as well as sharing them. Visibility into activities is often limited, making mismanagement or flawed processes difficult to discover and track. To mitigate these issues, many organizations are simplifying their processes using code-signing- as-a-service approaches. Code-signing-as-a-service can accelerate the steps required to get code signed, while making it easier to keep code secure. A robust solution can empower organizations with automation, enabling teams to minimize manual steps and accelerate signing processes. APIs can enable it to integrate seamlessly with development workflows and automated scheduling capabilities enable organizations to proactively and approve signature windows to support new releases and updates.

To strengthen accountability throughout the process, administrators can apply permission- based access. Strictly controlling access helps improve visibility into which users are allowed to sign code and which certificates and private keys they are allowed to utilize.

Standardizing workflows

Standardizing code signing workflows can also help reduce risk to an organization. Instead of allowing everyone in an organization to use the same key for signing, many organizations are using separate code signing keys for different DevOps teams, while granting administrators visibility over key usage. This best practice helps minimize the risk of mistakes that can occur across a company by limiting the ability of breaches to propagate. For example, if a key is used to sign a release that has been compromised, only one team’s code will be impacted.

Maximum flexibility to minimize risk

Key management flexibility is another helpful best practice, reducing risks by enabling administrators to specify shorter certificate lifetimes, rotate keys and control keypairs. For example, Microsoft recognizes publishers that rotate keys with higher reputation levels. With the right key management approach, an administrator could specify a specific number of days or months exclusively for files designed for use in Microsoft operating systems.

Secure key storage offline except during signing events

Taking keys offline is another measure that can secure code signing. With the right code signing administrative tool, administrators can place keys in a “offline mode,” making it impossible to use them to sign releases without the proper level of permission in advance. Release planning is a fundamental to software development, so most developers are comfortable scheduling signatures for specific keys directly into their processes.

Taking keys offline is a strong step to ensure that keys will not be used in situations where they should not be. It also adds a layer of organizational security by splitting responsibilities between signers and those who approve them—while providing improved visibility into which keys are signed by whom.

Freeing up developers to do what they do best

It’s clear that safeguarding DevOps environments correctly remains challenging, but fortunately the right management tools can minimize hassles—and maximize protection. As we’ve discussed, automation is essential for applying security across CI/CD pipelines. Seek out a solution that can fit smoothly within workflows and free up engineers from individual steps required for cryptographic asset protection. The tool should make signing keys easily accessible when pushing code and automate signing of packages, binaries and containers on every merge to master when authorized. Organizations also need a process for testing code integrity before they sign. A centralized, effective signing management tool can handle the signing tasks, while integrating with other systems that perform necessary integrity tests. For key security, the solution should provide the option of storing the keys offline in virtual HSMs. During a signing event, it should enable developers to access the keys to sign with one click, then return them back to secure offline storage

DevOps pros work within a variety of environments, so the signing solution should support portable, flexible deployment models via SaaS or on a public or private data center. Businesses in every industry are becoming increasingly software-driven and the challenges to DevOps organizations won’t disappear anytime soon. However, with the right approach to code signing, organizations can dramatically strengthen their security posture, minimize their chances of becoming the next victim and ensure customer confidence in their solutions.


(*) Disclosure: This podcast was sponsored by Digicert. For more information on how Security Ledger works with its sponsors and sponsored content on Security Ledger, check out our About Security Ledger page on sponsorships and sponsor relations.

This week, the New York State Department of Financial Services (NYDFS) issued the Report on the SolarWinds Cyber Espionage Attack and Institutions’ Response. The Report begins with the statement that “The next great financial crisis could come from a cyber-attack,” And goes on to describe how the SolarWinds attack affected financial institutions and NYDFS’s response assisting financial institutions in its aftermath.

The Report states that “the SolarWinds Attack is, to date, the most visible, widespread, and intrusive information technology (“IT”) software supply chain attack – i.e., a cyber-attack that corrupts IT software and uses that software as an attack vector. Supply chain attacks are dangerous because the malware is embedded inside a legitimate product, and because supply chain attacks can allow an attacker to access the networks of many organizations in a single stroke.”

For this reason, the Report further notes that “this attack confirms the importance of vigorous third party risk management, which starts with a thorough assessment of an organization’s third party risk. Third party risk management is a key part of DFS’s Cybersecurity Regulation, and the Department is exploring ways to further address this critical component of cybersecurity.”

The Report also addresses the lack of transparency in information sharing regarding cybersecurity attacks and indicates that NYDFS is interested in improving information sharing and transparency among its regulated covered entities.

The Report summarizes the background facts of the SolarWind attack, remediation efforts taken by companies affected by the attack, recommendations to strengthen cybersecurity practices, and measures taken to respond to the attack.

The United States government, states, municipalities, and private companies all have been trying to defend themselves from cyber warfare from foreign adversarial governments, including Russia, China, and North Korea, for years—actually, for decades. Even when I started practicing full time in this area of law in the early 2000s, we were talking about not traveling to those countries with work laptops for fear that data on the laptop would be stolen or misappropriated.

Every time a foreign adversarial government attacks a U.S. government agency or business with a cyberattack, it should be viewed like what it is: a bomb. Although it does not blow up bricks and mortar, it blows up the ability for the target to do business and forces it to rebuild its network and system in order to function. Every time a ransomware or malware code, or other bug, virus, or malicious tool is downloaded into a system, it should be viewed as what it is as well: an act of war by an adversary.

Last week, President Biden called out Russia for its part in wreaking havoc on tens of thousands of businesses when it launched the SolarWinds attack, and put sanctions in place. This will not be the last word in cyber warfare.

Russia and other foreign adversaries have sophisticated capabilities in cyber warfare. We don’t want to talk about it, but cyber warfare could cripple the economy, critical infrastructure, monetary transactions, health care, food supply, access to accurate information, communication, and our livelihoods. Everything is connected to the internet. Everything. And everything is vulnerable to cyber warfare.

Take time to determine what you would need in the face of cyber warfare. I liken it to what you would need if a very powerful hurricane came through, taking out the power, the water, the banking system, the grid, the ability to use a credit card (because there is no power), to get food and sustenance, gas or electricity for your car, or to get medical supplies or treatment. Some thoughts about what to stock up on include cash, a generator or other power supply, potable water, non-perishable food, medical supplies, an alternate form of communication and supply of energy, an escape route, and an escape plan. Whether it is cyber warfare, a hurricane, or worse, preparing for an emergency will help you weather it, and hopefully, the preparation will never be needed.

This week’s podcast is sponsored by Intel. In it, we speak with Intel’s Suzy Greenberg about a recent study Intel sponsored with the Ponemon Institute looking at the need for greater vendor transparency around cyber security. Suzy is a vice president at Intel and general manager of security communications and incident management in the Intel Product Assurance and Security group.


The compromise of firms such as SolarWinds and Accellion in recent months have made clear to everyone that the fate of your organization’s cyber security concerns doesn’t stop at the firewall. Indeed, as digital transformation takes hold across industries, the security of the software providers and third parties is now integral to the security and safety of pretty much every organization. Security teams, trained to monitor corporate perimeters and network traffic, now need to concern themselves with flaws buried deep in third party products and attacks that come wrapped as software updates. 

Episode 208: Getting Serious about Hardware Supply Chains with Goldman Sachs’ Michael Mattioli

Suzy Greenberg is a vice president at Intel and general manager of security communications and incident management in the Intel Product Assurance and Security group.
Suzy Greenberg, Intel Corp.

But what does that increasing reliance and interdependence mean for the relationships between software providers and their customers, particularly around information about software flaws and vulnerabilities? Do software and service providers owe it to their customers to be fully transparent about flaws or weaknesses in their platforms even in advance of patches, or is the byword still “say nothing unless asked”?

Those are questions I put to our guest this week. Suzy Greenberg is a vice president at Intel and general manager of security communications and incident management in the Intel Product Assurance and Security group. Suzy leads the execution of Intel’s global security communications strategy as well as the company’s response to matters involving product assurance and security.

In this conversation, Suzy and I talk about a survey (PDF) the company conducted with the Ponemon Institute to measure attitudes about vendor transparency about security. Among the survey’s findings: 47% said that their technology provider does not provide transparency surrounding security updates and mitigations. 

Futility or Fruition?Rethinking Common Approaches To Cybersecurity

To start off, I asked Suzy about Intel’s Product Security  Incident Response Team (PSIRT) and how the company that makes the chips that power modern technology manages its own product security challenges. You can check out the full podcast above or download the MP3.


As always,  you can check our full conversation in our latest Security Ledger podcast at Blubrry. You can also listen to it on iTunes and check us out on SoundCloudStitcherRadio Public and more. Also: if you enjoy this podcast, consider signing up to receive it in your email. Just point your web browser to securityledger.com/subscribe to get notified whenever a new podcast is posted. 

Binary Check Ad Blocker Security News

Cybersecurity firm SonicWall Inc. is investigating an attack on its internal systems that it describes as “highly sophisticated.” According to SonicWall, the investigation is centered around its Secure Mobile Access 100 series, which assists with end-to-end secure remote access.

The company said that a few thousand devices have been impacted and that it is trying to determine whether the attackers exploited a zero-day vulnerability in the SMA 100 series product.

Although it sounds very similar to the recent SolarWinds cyber-attack, it is presently unknown whether this incident is related to that attack or if it was caused by the Russian-based attackers behind the SolarWinds incident.

It is clear that cybersecurity firms are being heavily targeted by cyber-attackers and are not immune from the onslaught of cyber-attacks we are seeing across the board in every industry. It also emphasizes the fact that there is no ability to completely transfer cyber risk. Data security is a team sport. Reasonable cyber-hygiene inside your organization, while using outside tools to augment your security posture, are both ways to minimize risk, but hackers are using more and more sophistication in their attacks, which present risk internally and externally. What is crystal clear from these attacks on cybersecurity firms is that cybersecurity and vendor management must continue to be a high priority for organizations in order to manage cyber risk.

Binary Check Ad Blocker Security News

Malwarebytes, a cybersecurity firm, confirmed this week that the same hackers believed to originate from Russia who were behind the SolarWinds incident were able to access some of its internal emails without authorization.

According to the company, it did not use SolarWinds software, but had been targeted by the same hackers to access its O365 and Azure environments. It further stated that the access included a limited number of internal company emails, but did not include any access or compromise of its production environments, which is good news for its customers.

The CEO of Malwarebytes stated that the hacking campaign that started with FireEye and has affected both governmental agencies and Fortune 500 companies alike “is much broader than SolarWinds and I expect more companies will come forward soon.”

The fallout from these incidents continues, and no doubt there will be more to come.

Binary Check Ad Blocker Security News

The fallout from the SolarWinds hacking incident linked to Russian threat actors has not only wreaked havoc on governmental agencies and private companies whose data are at risk following the incident, but this week, Bitsight and Kovrr released an analysis outlining the effect of the event on insurance losses that estimates the incident could cost more than $90 million when all is said and done.

The $90 million includes costs related to forensic analyses, incident response, potential regulatory fines and public relations costs. Although it has been reported that 18,000 customers of SolarWinds may have been affected by the incident, the analysis indicates that 40 specific firms were targeted in the incident, 80 percent of which are located in the U.S. It further notes that those firms were primarily federal agencies or in the information technology sector.

The analysis highlights the importance of assessing supply-chain cyber risk and how supply chain and vendor security incidents can cause direct losses that may not be easily recoverable from downstream companies. As part of the assessment, companies also may wish to determine whether insurance coverage may be available if it experiences a vendor or supply chain incident like the SolarWinds example.

ICYMI, on Wednesday, January 6, 2021, the United States Department of Justice (DOJ) issued an update about what it termed “a major incident under the Federal Information Security Modernization Act”: the global SolarWinds cyberattack that had compromised its email system. (SolarWinds is a software provider. In December, 2020, SolarWinds revealed that cybercriminals had injected malware into its Orion® Platform software, a platform used for centralized IT monitoring and management. In doing so, the cybercriminals were able to attack subsequent users of the software, i.e., SolarWinds’ clients, including multiple federal agencies and technology contractors.) The DOJ’s update advised that after removing the malware, it determined that 3 percent of the DOJ’s O365 mailboxes were potentially accessed, albeit there was no indication that any classified systems were impacted. This update was covered by Robinson+Cole’s Data Privacy + Cybersecurity Insider.

Cyber-crime continues to permeate all industries, including real estate development and construction. The SolarWinds incident could just as easily have occurred with a construction management company or general contractor using the construction industry’s various project management software programs. Digital attacks can intercept sensitive information, divert funds and hold hostage a company’s computer systems. Robinson+Cole’s Construction Group is available to discuss the value of adding data privacy and cybersecurity protocols to design and construction agreements, and its Data Privacy + Security Team is available to assist businesses in determining their current risks and liability exposure as well as the benefits of having cyber-liability insurance coverage.

This post was authored by Virginia Trunkes and is also being shared on our Construction Law Zone blog. If you’re interested in getting updates on current developments and recent trends in all areas of construction law, we invite you to subscribe to the blog.

Development and Operations (DevOps) teams are often pressured by executives and sales teams to get software products completed and out the door and into the market as quickly as possible so the products can generate income. Often, security is not the highest priority for DevOps, as adding security features may affect the performance of the software or add time to the deployment schedule.

The SolarWinds hack is a crucial reminder to DevOps teams to build security into software products, and to complete due diligence on the security protocols regarding the DevOps teams of vendors that make components used by software manufacturers, such as JetBrains.

JetBrains is a Czech-based company that developed a product called TeamCity, which Reuters reports is “used by tens of thousands of customers to construct other software.” According to other news reports, the FBI is investigating whether the Russians hacked into JetBrains’ TeamCity DevOps tool in order to infect SolarWinds’ Orion software [see related post].  If your DevOps team is using TeamCity, it may present another risk associated with the SolarWinds incident that has much broader impact on other software development.

Check with your DevOps team to see what kind of security due diligence they are completing on the vendors that are providing the component parts of the software they are developing, including JetBrains. If no due diligence is being done, this is a perfect time to start.