Scott Johnson from Black Duck Discusses Open Source Software Risk Management and the Need for Empathetic Listening in Security

We interacted with Black Duck’s VP of Product Management, Scott Johnson, and realized that the product team can drive success and bring innovation in ways that are seldom highlighted. 

With over 20 years of experience in cyberspace, Johnson strongly believes in execution, i.e., doing what you promised, which builds trust among customers.

Johnson leads the product direction for SaaS and on-premise AppSec solutions with a focus on empathetic listening, so he understands customer needs, which solves half the challenge. 

Learn his success mantra, which includes a mix of technical knowledge, an understanding of finance and marketing, and a touch of salesmanship in this interview.

Read on to learn more about the role of curiosity in cybersecurity, exploring ways to solve problems, and the power of listening. 

1. Keeping your success in product management in view, we would like to know what skills and traits helped you give your best to the company. Please also share the challenges that you faced and how you overcame them.

Unlike other disciplines in the tech industry, product management isn’t about having one particular skill but rather being able to incorporate key inputs across disciplines to solve market needs for customers.  The skills and traits that have worked for me and might also work for others center first on truly having a curiosity about the market you are in. 

For me, that has been cybersecurity, an industry within which I’ve worked, and I’ve been curious about for the past 20 years. When you are curious, you explore. When you explore, you learn. When you learn, you identify ways to solve problems that you didn’t think were solvable. 

Next is listening empathetically to users to understand what their needs are. When you listen and share back what you heard, you ensure the user or customer knows they are being heard. And when you understand their challenge, you develop a deeper understanding of their situation. 

Sometimes customers just need to be heard, as opposed to being spoken to. 

The third is execution. Do what you said you were going to do. That builds trust when customers and the market know that you are delivering on your roadmaps and keeps them coming back for more.

Be curious, listen with empathy, and execute. Underpin that with a mix of technical knowledge, an understanding of finance and marketing, and a touch of salesmanship, and you will most likely be successful—not just in product management but in many aspects of business. 

Build and foster relationships built on those principles along the way. I would also encourage reading about and listening to the history of other companies, as knowing the history of Nvidia, Facebook, Rolex, Mars, and others truly provides insight and perspective that is beneficial in the practice of product management.

2. After completing your MBA, you co-founded a company and moved on to have a steady career in product management. Fresh graduates, entrepreneurs, and others could learn from your experience. Please give us your insights about what you learned during these changes in your career.

I earned my MBA in Entrepreneurship at the University of Iowa. Our lead professor was the late Ed M. Moldt, who also taught at the University of Indiana and was Managing Director at the Snider Entrepreneurial Center at the Wharton School of Business. 

A key learning at the time of my graduation, and when I went on to co-found Ho-Chunk, Inc., a leading Native American economic development company for the Winnebago Tribe of Nebraska, was the emphasis on value. 

Deliver value in all that you do, and customers and the market will respond positively to it. As part of that experience, I led most of the technical efforts early on for the company, from websites to computer networking. 

In addition to providing value, I learned how technology can help accelerate the time to value. When I relocated to Atlanta due to my wife’s career, I transitioned into network sales at Bellsouth and was selected for their top training course in tech called Data Leap, which after completion they asked me to also be an advisor for future students. 

We learned everything from the OSI model to T1 bandwidth architecture. That experience led me to ask more questions about why some of the products were designed the way they were, and that is when someone else in sales said, “You need to be in product management, Scott.” 

Next thing I knew, I was creating requirements for web page solutions targeting small- and medium-sized companies while in parallel co-founding the Product Management Society with the Technology Association of GA. 

A key learning in that process was defining the experience for the user such that you could communicate that to the developers. There is a skill in communicating the business or customer problem, leading most importantly to implementing a solution and driving appropriate guidance to the developers.

Apparently, that worked out for me as I was able to build my product career at companies like ISS, Fortify, and now with Black Duck. A big part of that centers on listening to customer needs, looking at where the market is evolving, and placing some bets on the best approach product- and solution-wise to address the challenges.

My guidance is to develop your journey based on some overarching goals. Take some risks along the way. That might mean joining or establishing a start-up or moving into a new area within a larger company. 

Don’t focus so much on ‘your career;’ rather, maintain a focus around continuously learning and building trusted relationships with people. No matter what, you will learn from it.  If not what to do, you will most certainly learn what not to keep doing. Find ways to tie stories to your message as those truly have more impact. 

I might be the only person that has given an AppSec presentation with quotes from Arthur Schopenhauer and the rock band Iron Maiden.  My point is to mix it up.  Make it interesting.  Make it matter. Make a difference!

3. Please walk us through your experience related to the transition of Synopsys SIG to Black Duck. Could you share your observations about how specific requirements were met, complexities addressed, and the workforce fortified?

It was crucial to carve out our business from Synopsys in order to create a new entity to further our goal of building trust in our customers’ software solutions, and we had gaps to fill as part of that. For example, we relied on Synopsys IT for almost all our infrastructure. 

We shared some of our other teams with Synopsys, so we had gaps in HR, Finance, etc., that we had to fill. The good news is that we knew this going into the process and had visibility into those changes. That didn’t make the transition easy, per se. 

For example, every employee’s SharePoint data moved to a Black Duck entity. We had to re-image our computers from Synopsys to Black Duck machines. While challenging, our partners, Francisco and Clearlake, have done this before and provided excellent guidance along the way.

While each company is different, we had a very thorough action plan with detailed lists of activities to follow with requirements. That really helped us manage those complexities. 

Rule 1 in a carve-out is to have a plan. It will change, and not everything will go according to plan. But having a plan gives you a path. 

Rule 2 is to stick to business. Put another way, maintaining a focus around our product execution and roadmaps to ensure there are minimal customer service interruptions and minimal innovation hindrances. 

Customers were reasonably optimistic about us becoming a new standalone entity, but they wanted to know that didn’t mean we would stop delivering on our product plans. To address this, we enabled tools like Aha! roadmap software to extend feature insight to customers while also making improvements to our Jira processes to better predict our releases. 

To date, we have been able to maintain our product execution with only a few minor issues tied to data center migration updates. On the workforce, a change like this does create uncertainty. 

The way we worked as a team to address that was to just be as honest as we could be about our vision and focus as a company—communicating clearly. While this takes time during a transition, we have seen it work with our team members in every part of our business. 

People know what is expected of them and we are better aligned on a common purpose for our journey that centers on ensuring the world can build trusted software at scale. It is both a challenging time and an exciting time. Most of us thrive on that mix of excitement and challenge.

4. Could you elaborate on certain application security risks and how to counter them?

What is certain is that if you have an application, you have security risks. We have to start with the premise that there is no such thing as ‘secure code’, but rather, it is about how to ensure the lowest possible risk related to the potential impact the risk could have for an organization and its customers. 

A high risk for a non-essential application could still create a situation where the exploitation of that vulnerability leads to lateral movement into other applications that are mission-critical. 

The weakest link theory (widely attributed to English writer William James around the time the first punch card system was created) applies here and, as a result, means that companies must look at application risks across their organization and not just app by app. 

At a high level, the risks center on vulnerabilities in the code, misconfiguration, license and IP issues, and general weaknesses in design.  You can mitigate those by following best design practices and code reviews, leveraging application security testing tools like the ones we offer at Black Duck, training, etc. 

More specifically, you have injection types of attacks like SQL and cross-site scripting (XSS) which can lead to security breaches and malware injection. There are areas that impact applications, such as weak authentication and session management, as well as sensitive data exposure, which can lead to data breaches and data exfiltration. 

These can be mitigated by ensuring MFA is in place, supporting TLS encryption for data in transit, and even leveraging data masking. Some of that goes beyond AppSec but is certainly related to overall application protections. 

And, of course, great practice centers on ensuring you are not including components with known vulnerabilities, such as an outdated library or plugin. Open source software (OSS) security tools like Black Duck SCA can support the mitigation of those issues.

5. Please share your perspective on open-source risk management.

Overall, OSS has known vulnerabilities and license risks that by themselves create risks for the organization creating them. In a supply chain world, the downstream impact is amplified as more companies use 3^rd party software to build their products. 

In the 2025 OSSRA report, 64% of the open source components identified in our scans were transitive dependencies—open source libraries that other software components rely on to function.

These dependencies represent suppliers that are 2 or 3 levels removed from the actual product being used. This is the case in automotive, for example. The result is that the product owner may not be aware of that risk unless sufficiently detailed in the SBOM. 

This increases the need to ensure the identification of all components, from license and version to any known vulnerabilities. It goes beyond just OSS risk management now, it is a compliance and regulatory need, with potential legal consequences. Lower the risk with tools like Black Duck SC,A and you lower possible legal impact over time as well.

6. Could you provide insights about open-source license risk and compliance for developers and companies?

The key element here is ensuring visibility for developers and the organization for which they work. Oftentimes, the risks might be known in the open source components but not identified in the components the developer is working on and pulling from source repositories. 

While developers today are certainly more ‘security aware’ when it comes to writing code, their primary focus remains on meeting timelines and objectives for their organizations. 

Compliance comes after the fact for them in many cases or is not viewed as their responsibility. That is changing now, given the regulatory environment and SBOM requirements. 

The insight for developers and their organizations centers on ensuring policy, training, and enforcement. 

• Policy ensures that there are usage guidelines in place for using and contributing to OSS and can include providing repositories with approved components in terms of license usage and vulnerability risks. 
• Training centers on continuing fundamental best practices and leveraging remediation guidance. 
• Enforcement centers on not only assessing the source code or binaries with tools like Black Duck SCA, but also validating SBOM generation with dependency mapping, license obligations, and the ability to include custom components. 

Today’s highly interconnected software supply chains also impact the software components in physical products such as a sensor or braking system within a car; whereby, in many cases, they must be more durable than the physical components they power and support. 

That is a paradigm shift for all.