In speaking with over two hundred Supply Chain Managers executives and M&A experts over the past 4 months, I realized that there is a lot of misunderstanding about it. Buyer’s Side (PE and VCs) skip the process because they are not aware of the benefits, scared by the “complexity” or consider it expensive. The vendor side overprotects their code, and the developers keep the quality of the code a closely guarded secret.

• Almost everyone has a hard time getting access to the source and thinks that scanning the source code is equivalent to manual code inspection.

Code without code sharing (“blind” audit). Available only by CWT

• How much more so is “technical debt” seen as a black box.

CWT clearly defines software quality and the deviation from the actual state (the Technical debt). User defined quality benchmarks are supported too.

• Almost everyone mixup Source Code Analysis (scanning) with Software Composition Analysis (probably because both could be abbreviated as SCA). The former supports the evaluation of the privately owned code, while the latter assesses the security and the license compliance of the integrated 3rd party components (OSS and Commercial). We need both.

CWT supports both!

• Although a thorough M&A analysis requires both, the vast majority of existing products support either the Software Composition Analysis (BlackDuck Hub, Snyk, Mend, Fossa), only the Source Code Analysis (SonarQube, Coverity). Very few products support both (CodeWeTrust, Checkmarx, Veracode)

CWT classified as one of the top products worldwide check:

Global Source Code Analysis Software Market Size & Forecast

• Almost none realize that it is not humanly possible to inspect quality and estimate technical debt on any average sized modern codebase, manually. At best, a single branch could be sampled and a weak (for M&As) qualitative (not quantitative) analysis could be compiled.

CWT Automated source code assessment could be completed in hours, while (partial) manual assessment lasts for weeks or months (guess the cost difference!-you pay more for less).

That’s why I thought I’d chat with an entity that probably holds a good percentage of the world’s knowledge (by 2021) and is famous for its accurate answers: ChatGPT. It’s also biased, but not like I am, since openAI doesn’t offer any source code analysis product (as far as I know).

All of the prompts here are unedited

Source code scanning on M&As

Me: Do I have to use source code scanning on a M&A? Isn’t it “too much”?

Open AI GPT-3: Source code scanning can be a useful tool during a merger or acquisition (M&A) process to help assess the security posture and potential risks of the target company’s software. However, whether or not you should use source code scanning during an M&A depends on the specific circumstances of the deal.

If the target company has developed or acquired software that is critical to its operations, you may want to use source code scanning to identify any security vulnerabilities, potential intellectual property issues, or other risks that could impact the value of the target company. Source code scanning can also help identify any potential regulatory compliance issues related to the software.

However, if the software is not critical to the target company’s operations or if the M&A is not focused on the technology assets of the target company, source code scanning may not be necessary.

Ultimately, the decision to use source code scanning during an M&A should be based on a thorough risk assessment of the target company’s technology assets, including software. You should consult with experts in both cybersecurity and M&A to determine the appropriate level of due diligence for your specific situation.

Me: I thought about scanning the source code in a M&A, but the target company refused to share the code. Should I forget about it?

Open AI GPT-3: If the target company is not willing to share their source code for scanning as part of the due diligence process, it can be challenging to fully assess the security risks and potential issues with their software. However, there are other ways to try and gather information and assess the risk.

First, you may want to ask the target company if they have any reports or assessments from third-party security firms or if they have performed any security testing on their software. These reports can provide some insight into potential vulnerabilities or other security issues.

You could also try to review documentation and other artifacts related to the software, such as architectural diagrams, user manuals, design documents, and functional specifications, to gain a better understanding of the software and how it works.

Additionally, you may want to consider engaging a third-party security firm to conduct a review of the software without access to the source code. This firm could conduct a “black-box” assessment of the software, which involves testing the software from the outside without access to the internal workings of the application. While this approach may not provide the same level of detail as a source code review, it can still identify potential security issues.

Ultimately, the decision to proceed with the M&A without access to the source code will depend on the level of risk and uncertainty that you are willing to accept. You should consult with legal and security experts to evaluate the risks and help you make an informed decision.

Me: They told me that source code scanning is too complicated to be managed within the narrow time frame of an M&A. Is this correct?

Open AI GPT-3: It is true that conducting a thorough source code scan can be a complex and time-consuming process, especially if the software is large and complex. However, it is also possible to conduct a more targeted source code review that focuses on specific areas of concern. This approach can help to identify potential issues and provide a high-level assessment of the overall quality of the software within a more limited timeframe.

Additionally, there are many tools and services available today that can automate the process of source code scanning and provide a quick and accurate assessment of the software. These tools can help to speed up the due diligence process and provide a more comprehensive view of the technical debt and other software quality issues.

That being said, the decision on whether to conduct a source code scan as part of an M&A due diligence process depends on the specific circumstances of the acquisition, such as the nature of the software, the level of risk, and the timeline of the acquisition. It may be possible to rely on other methods of assessing technical debt, as we discussed earlier. Ultimately, it is important to consult with legal and technical experts to evaluate the risks and make an informed decision on how to proceed

Code assessment without code scanning

Me: I understand that it’s possible to access security to some extent, but i don’t understand how I can assess the technical debt without scanning the code

Open AI GPT-3: You are correct that the most accurate way to assess technical debt is through source code analysis. However, there are ways to estimate technical debt without source code access.

One way to do this is to look at the overall complexity and maintainability of the software. This can be evaluated by examining the software architecture, design documents, and development processes used by the target company. For example, you could review documentation and ask questions about how the software is designed, how it is tested, and how it is deployed. You could also ask about the processes that the target company uses to manage technical debt and ensure that software development best practices are being followed.

Another way to estimate technical debt is to review the performance of the software in production. This can be done by analyzing metrics such as the frequency of incidents, downtime, and customer complaints. If the software is experiencing a high rate of incidents or downtime, it could be an indication of significant technical debt. Similarly, if customers are complaining about the quality or usability of the software, this could be an indication that the software is not being developed or maintained to a high standard.

You could also conduct interviews with key stakeholders in the target company, such as software developers, architects, and product managers, to gain a better understanding of their perspective on the state of the software. This can provide insight into any challenges or obstacles that they are facing in developing or maintaining the software.

While these methods may not provide as accurate an assessment of technical debt as source code analysis, they can still provide valuable insights into the state of the software and help to identify potential risks or issues that could impact the success of the acquisition.

Me: I do agree, but there is a major risk. Interviews, Architecture diagrams, even performance metrics on a selected deployment might transfer a very optimistic assessment, while the code scanning ensures a much more thorough quality inspection

Open AI GPT-3: You are absolutely right that relying solely on interviews, architecture diagrams, and performance metrics can be risky, as they can give an overly optimistic view of the target company’s software quality. Code scanning is a much more thorough quality inspection that can provide a deeper understanding of the software and the level of technical debt.

That being said, if the target company is not willing to share their source code, you may not have the option to conduct a code scan. In this case, it is important to use a combination of other methods to evaluate the technical debt and the overall quality of the software, as I described earlier.

It is also important to keep in mind that due diligence is a balancing act. While it is important to conduct a thorough assessment of the target company’s software, it is also important to consider the cost and time involved in the due diligence process. In some cases, it may be more practical to rely on other methods to assess technical debt rather than insisting on a code scan that the target company is not willing to provide.

Ultimately, the decision on how to proceed will depend on the specific circumstances of the acquisition and the level of risk that the acquiring company is willing to accept. It is important to consult with legal and technical experts to evaluate the risks and make an informed decision.

Me: I have to assess a software product as a part of an M&A (Acquisition) . I have received a high level description of the architecture and a bunch of flow charts but I don’t have access to the code. How can I be sure the product has been implemented as described and I haven’t received just a bunch of wishful thoughts?

Open AI GPT-3: Assessing a software product without access to its source code can be challenging, but there are several steps you can take to gain confidence in the product’s quality and alignment with the architectural description provided:

1. Review the documentation: Carefully review the architectural description and flow charts to ensure that they are comprehensive and detailed enough to accurately represent the product’s functionality. Look for any inconsistencies or omissions that may suggest the documentation is incomplete or inaccurate.
2. Conduct interviews: Talk to the development team and other stakeholders to confirm the accuracy of the architectural description and gain insight into the product’s development process. Ask questions to ensure that everyone involved has the same understanding of the product’s architecture and functionality.
3. Conduct testing: Use the product to test its functionality and ensure that it aligns with the architectural description. Use test cases that cover all critical features of the product to validate that it works as intended.
4. Conduct a code review: Even if you do not have access to the source code, you can ask the development team to provide an overview of their coding practices and standards. This can provide insight into the quality of the code and the development team’s adherence to industry best practices.
5. Check references: Ask for references from other clients who have used the product to confirm its effectiveness and alignment with the architectural description.
6. Consider hiring a third-party auditor: If you are unsure about the accuracy of the architectural description or your ability to assess the product’s quality, consider hiring a third-party auditor who can review the documentation, conduct testing, and provide an objective assessment of the product’s quality and alignment with the architectural description.

Me: Good answer but I cannot conduct interviews with the developers due to the confidentiality of the M&A . Only the c-suite is aware of it

Open AI GPT-3: If you cannot conduct interviews with the development team due to confidentiality concerns, you can still take the following steps:

1. Engage an independent expert: Consider hiring an independent expert who is experienced in reviewing software products and can evaluate the product’s architecture and documentation without access to the source code.
2. Review the product’s history: Look into the product’s development history, including the team’s experience and qualifications, the development process and methodologies used, and any relevant industry standards or regulations.
3. Review relevant documentation: Review any relevant documentation, such as project plans, requirements documents, design documents, and test plans to gain insight into the development process and the product’s intended functionality.
4. Analyze the flow charts: Analyze the flow charts provided to confirm that they are comprehensive and detailed enough to accurately represent the product’s functionality. Look for any inconsistencies or omissions that may suggest the documentation is incomplete or inaccurate.
5. Check for regulatory compliance: If the software is designed for a specific industry or market, ensure that it complies with all relevant regulations and standards.
6. Engage a third-party audit firm: Consider engaging a third-party audit firm that specializes in software product reviews to provide an independent assessment of the product’s quality and alignment with the architectural description.

While conducting interviews with the development team can provide valuable insight, there are other steps you can take to evaluate the product’s quality and alignment with the architectural description, even if you cannot speak directly with the development team.

Me: Is this more accurate and reliable than simply scanning the code?

Open AI GPT-3: No, reviewing the source code of the software is generally considered to be the most accurate and reliable method of assessing the quality of a software product. By examining the code, you can gain a detailed understanding of how the software is implemented and identify any issues or potential areas of concern. However, reviewing the source code is not always feasible or practical, especially in cases where the software is proprietary or confidential.

In cases where access to the source code is restricted, a combination of methods, such as reviewing documentation, analyzing flow charts, conducting testing, and engaging independent experts, can provide a reasonable level of confidence in the software’s quality and alignment with the architectural description. However, these methods may not be as accurate or reliable as reviewing the source code, as they rely on interpreting documentation and other artifacts rather than direct inspection of the code.

Me: BTW I have been told that the code is huge. Bigger than 0.5M LOC, and includes a mixup of tech stacks. How would it be possible for a single person , even an experienced one, to assess the code manually, within the M&As narrow time frame?

Open AI GPT-3: Assessing a software codebase of over 0.5 million lines of code (LOC) that uses multiple technology stacks is a complex and time-consuming task, and it would not be feasible for a single person to review and assess the code manually within a week, especially without any prior knowledge of the codebase. In this scenario, you may need to consider alternative approaches or engage external experts to assist with the assessment process.

One option is to use automated analysis tools, such as code analysis and code quality tools, which can quickly scan the codebase and identify potential issues or areas of concern. These tools can provide an initial overview of the codebase, allowing you to focus your attention on specific areas that require more detailed review.

Another option is to engage external experts who have experience in reviewing software codebases of similar size and complexity. These experts can provide a more in-depth review of the codebase and identify potential issues or areas of concern, leveraging their experience and knowledge of best practices in software development.

It’s important to note that a thorough assessment of a codebase of this size and complexity can take several weeks or even months, depending on the level of detail required and the complexity of the software. It’s essential to allow enough time for a comprehensive assessment to ensure that you can make an informed decision about the software product as part of the M&A process.

SCA vs SCA!

Me: As an alternative to the code scanning I have been suggested to use an SCA tool (Software Composition Analysis). Is this sufficient?

Open AI GPT-3: Software Composition Analysis (SCA) is a useful tool for identifying and managing the use of third-party software components and libraries within a software application. An SCA tool analyzes the software dependencies and identifies any known security vulnerabilities, licensing issues, or other risks associated with those components.

While an SCA tool can provide valuable insights into the composition of a software application, it is not a substitute for a source code scan. SCA tools focus on identifying risks associated with third-party software components, while a source code scan provides a more comprehensive assessment of the quality of the code itself, including potential security vulnerabilities, coding errors, and maintainability issues.

That being said, using an SCA tool can be a useful complement to a source code scan, especially in situations where the target company is not willing to share its source code. By analyzing the software dependencies, an SCA tool can provide some insight into the level of technical debt and the overall quality of the software.

In summary, while an SCA tool can provide some value as part of an M&A due diligence process, it is not sufficient on its own to provide a comprehensive assessment of the software. A source code scan is still the most accurate way to evaluate the technical debt and other quality issues within the software.

Me: Is there any chance the technical debt will ruin the success of the acquisition?

Open AI GPT-3: Yes, technical debt can be a significant risk to the success of an acquisition. Technical debt is a metaphor used to describe the accumulation of software development inefficiencies, such as incomplete documentation, suboptimal design choices, and shortcuts taken to meet deadlines. Over time, technical debt can slow down development and increase the cost of maintaining and improving the software, ultimately hindering the ability of the software to support the goals of the acquisition.

If the target company has a high level of technical debt, this can create several problems that could impact the success of the acquisition. For example:

1. Slower time-to-market: Technical debt can slow down the pace of software development, leading to delays in delivering new features or products that were a key driver of the acquisition.
2. Higher development costs: Accumulated technical debt can make software development more time-consuming and expensive, which could impact the financial success of the acquisition.
3. Security risks: Technical debt can increase the risk of security vulnerabilities in the software, which could expose the acquiring company to potential data breaches or other security incidents.
4. Reduced innovation: Technical debt can make it difficult to implement new ideas or incorporate new technologies, which could hinder the acquiring company’s ability to innovate and keep up with changing market demands.

Therefore, it is essential to evaluate the level of technical debt in the target company’s software during the due diligence process of an acquisition. If significant technical debt exists, the acquiring company should carefully consider the potential impact on the success of the acquisition and plan accordingly. This could include strategies such as investing in software modernization, refactoring, or even a complete rewrite to reduce technical debt and ensure long-term success.

Me: Should I base my technical debt assessment solely on SCA tools like Black duck hub, whitesource and Snyk?

Open AI GPT-3:: Software Composition Analysis (SCA) tools like Black Duck, WhiteSource, and Snyk are useful for identifying open source components and their associated vulnerabilities or license risks in a codebase. However, relying solely on SCA tools to assess technical debt may not provide a complete picture of the codebase’s overall health.

Technical debt refers to the cost of maintaining a codebase over time, and it includes issues such as code complexity, lack of documentation, poor design, and inefficient algorithms, among others. While SCA tools can identify security and licensing issues, they may not detect these broader issues.

To assess technical debt comprehensively, it’s important to consider a range of factors, including code complexity, test coverage, code duplication, maintainability, and scalability. These factors can be assessed through a combination of manual code reviews, automated code analysis tools, and software testing.

Manual code reviews are an essential component of assessing technical debt, as they allow for a deep dive into the codebase to identify potential issues and areas for improvement. Automated code analysis tools, such as static analysis tools, can also be used to identify potential issues, including code smells, performance issues, and security vulnerabilities. Additionally, software testing can help identify potential issues in the code, such as bugs or inefficient algorithms.

In summary, while SCA tools can be a useful component of assessing technical debt, they should be combined with other methods, including manual code reviews, automated code analysis tools, and software testing, to provide a comprehensive assessment of the codebase’s overall health.

Me: So which are the differences between Software Composition Analysis and and Source Code Scanning?

Open AI GPT-3:: Software Composition Analysis (SCA) and source code scanning are two distinct types of analysis used in software development and security.

SCA tools focus on identifying and managing the use of third-party software components within a codebase, typically open-source components. SCA tools use a combination of software fingerprinting and vulnerability databases to identify the components used in a codebase and any associated security or licensing risks. The focus is on identifying vulnerabilities or license compliance issues in the components used in the codebase, rather than analyzing the code itself.

Source code scanning, on the other hand, involves analyzing the source code of an application for potential security vulnerabilities, programming errors, and other issues. Source code scanners use static analysis techniques to identify potential issues without executing the code. These tools analyze the code for issues such as buffer overflows, SQL injection vulnerabilities, and other common security issues.

In summary, while both SCA and source code scanning are important components of software development and security, they serve different purposes. SCA is focused on managing third-party components and identifying associated risks, while source code scanning is focused on analyzing the code for potential security vulnerabilities and programming errors.

Farewell…

Me: Thank you very much. Have a great millisecond!

Open AI GPT-3 : You’re welcome! If you have any more questions, feel free to ask. Have a great day!