CodeSentry: Difference between revisions
From EverybodyWiki Bios & Wiki
m remove duplicates internal links |
m automatic correction by IA |
||
| Line 1: | Line 1: | ||
{{AFC submission|d|adv|u=Wcg98|ns=118|decliner=DGG|declinets=20211213031855|reason2=corp|ts=20210929161214}} <!-- Do not remove this line! --> | {{AFC submission|d|adv|u=Wcg98|ns=118|decliner=DGG|declinets=20211213031855|reason2=corp|ts=20210929161214}} <!-- Do not remove this line! --> | ||
{{AFC comment|1=This | {{AFC comment|1=This is an advertisement, devoted to listing the features of the software. References fail WP:NCORP '''[[User:DGG| DGG]]''' ([[User talk:DGG| talk ]]) 03:18, 13 December 2021 (UTC)}} | ||
{{AFC comment|1=This page has been moved back from article space to draft space. Please read the comments by the draftifying reviewer and address them. Do not resubmit this draft without addressing the comments of the previous reviewer. If you do not understand why this article was sent back to draft space, ask the reviewer rather than simply resubmitting. | {{AFC comment|1=This page has been moved back from article space to draft space. Please read the comments by the draftifying reviewer and address them. Do not resubmit this draft without addressing the comments of the previous reviewer. If you do not understand why this article was sent back to draft space, ask the reviewer rather than simply resubmitting. | ||
| Line 25: | Line 25: | ||
}} | }} | ||
'''CodeSentry''' is binary [[software composition analysis]] tool developed by GrammaTech, first released<ref>{{Cite news|date=2020-10-27|title=GrammaTech Introduces CodeSentry™ to Identify Security Blind Spots in Third Party Code|language=en|work=Bloomberg.com|url=https://www.bloomberg.com/press-releases/2020-10-27/grammatech-introduces-codesentry-to-identify-security-blind-spots-in-third-party-code|access-date=2021-09-09}}</ref> on October 27, 2020, is based on their previous binary code analysis research.<ref>{{cite arXiv|last1=Kashyap|first1=Vineeth|last2=Brown|first2=David Bingham|last3=Liblit|first3=Ben|last4=Melski|first4=David|last5=Reps|first5=Thomas|date=2017-06-08|title=Source Forager: A Search Engine for Similar Source Code|class=cs.SE|eprint=1706.02769}}</ref><ref>{{Cite journal|last1=Katz|first1=Deborah S.|last2=Ruchti|first2=Jason|last3=Schulte|first3=Eric|date=2018-03-01|title=Using recurrent neural networks for decompilation|url=https://ieeexplore.ieee.org/document/8330222|journal=2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER)|pages=346–356|doi=10.1109/SANER.2018.8330222|isbn=978-1-5386-4969-5|s2cid=4611331}}</ref> This technology performs static analysis of binary executables, libraries and object files without the need for source code. An advantage of this binary analysis is the ability to analyze binary components when source code is not available, whether open source software<ref>{{Cite web|title=Open-source software vulnerabilities|url=http://magazine.aerospacemanufacturinganddesign.com/article/september-2021/open-source-software-vulnerabilities.aspx|access-date=2021-09-09|website=Aerospace Manufacturing and Design|language=en}}</ref> or third-party and commercial software. | '''CodeSentry''' is a binary [[software composition analysis]] tool developed by GrammaTech, first released<ref>{{Cite news|date=2020-10-27|title=GrammaTech Introduces CodeSentry™ to Identify Security Blind Spots in Third Party Code|language=en|work=Bloomberg.com|url=https://www.bloomberg.com/press-releases/2020-10-27/grammatech-introduces-codesentry-to-identify-security-blind-spots-in-third-party-code|access-date=2021-09-09}}</ref> on October 27, 2020, and is based on their previous binary code analysis research.<ref>{{cite arXiv|last1=Kashyap|first1=Vineeth|last2=Brown|first2=David Bingham|last3=Liblit|first3=Ben|last4=Melski|first4=David|last5=Reps|first5=Thomas|date=2017-06-08|title=Source Forager: A Search Engine for Similar Source Code|class=cs.SE|eprint=1706.02769}}</ref><ref>{{Cite journal|last1=Katz|first1=Deborah S.|last2=Ruchti|first2=Jason|last3=Schulte|first3=Eric|date=2018-03-01|title=Using recurrent neural networks for decompilation|url=https://ieeexplore.ieee.org/document/8330222|journal=2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER)|pages=346–356|doi=10.1109/SANER.2018.8330222|isbn=978-1-5386-4969-5|s2cid=4611331}}</ref> This technology performs static analysis of binary executables, libraries and object files without the need for source code. An advantage of this binary analysis is the ability to analyze binary components when source code is not available, whether open source software<ref>{{Cite web|title=Open-source software vulnerabilities|url=http://magazine.aerospacemanufacturinganddesign.com/article/september-2021/open-source-software-vulnerabilities.aspx|access-date=2021-09-09|website=Aerospace Manufacturing and Design|language=en}}</ref> or third-party and commercial software. | ||
== Binary Software Composition Analysis == | == Binary Software Composition Analysis == | ||
| Line 40: | Line 40: | ||
# '''Supplier Name''': The name of the software supplier and should include aliases. Supplier and author might be different if the supplier is making a claim on behalf of the author. | # '''Supplier Name''': The name of the software supplier and should include aliases. Supplier and author might be different if the supplier is making a claim on behalf of the author. | ||
# '''Component Name''': The name of the software component and possible aliases. | # '''Component Name''': The name of the software component and possible aliases. | ||
# '''Version String | # '''Version String''': The format of the version information is free form but should follow common industry usage. | ||
# '''Component Hash''': The best way to identify a component is the use of a cryptographic hash that acts like a unique identifier. The specifics of these are usually defined by the interchange formats agreed upon by the industry. | # '''Component Hash''': The best way to identify a component is the use of a cryptographic hash that acts like a unique identifier. The specifics of these are usually defined by the interchange formats agreed upon by the industry. | ||
# '''Unique Identifier''': A unique identifier is needed for each component. | # '''Unique Identifier''': A unique identifier is needed for each component. | ||
| Line 48: | Line 48: | ||
# '''Component Match''': This is the degree of confidence from the matching algorithm used by CodeSentry. Since the SBOM is automatically generated from binary code, matching to known components does have some degree of error. | # '''Component Match''': This is the degree of confidence from the matching algorithm used by CodeSentry. Since the SBOM is automatically generated from binary code, matching to known components does have some degree of error. | ||
# '''Security score''': Based upon identified components and discovered vulnerabilities ranked by criticality, a | # '''Security score''': Based upon identified components and discovered vulnerabilities ranked by criticality, a security score is generated to highlight the risk of the software application. | ||
# '''Path''': The file path of the component. | # '''Path''': The file path of the component. | ||
# '''CVE Distribution''': The distribution of discovered vulnerabilities by criticality (critical, high, medium and low.) | # '''CVE Distribution''': The distribution of discovered vulnerabilities by criticality (critical, high, medium and low.) | ||
Latest revision as of 22:20, 17 March 2026
| Developer(s) | GrammaTech, Inc. |
|---|---|
| Initial release | October 27, 2020 |
| Stable release | Version 2.0
/ June 29, 2021 |
| Engine | |
| Operating system | Crossplatform |
| Type | Software composition analysis |
Search CodeSentry on Amazon.
CodeSentry is a binary software composition analysis tool developed by GrammaTech, first released[1] on October 27, 2020, and is based on their previous binary code analysis research.[2][3] This technology performs static analysis of binary executables, libraries and object files without the need for source code. An advantage of this binary analysis is the ability to analyze binary components when source code is not available, whether open source software[4] or third-party and commercial software.
Binary Software Composition Analysis
CodeSentry uses multiple component matching algorithms for component detection across different Instruction Set Architectures (ISAs) and compilers. These algorithms compute and compare code signatures using properties ranging from lexical information such as the contents of strings or semantic abstractions of the high-level logic contained in functions.
Software Bill of Materials
The National Telecommunications and Information Administration (NTIA) defines a software bill of materials (SBOM)[5] as “as a formal record containing the details and supply chain relationships of various components used in building software. These components, including libraries and modules, can be open source or proprietary, free or paid, and the data can be widely available or access-restricted.”
CodeSentry creates a software bill of materials (SBOM) and lists known vulnerabilities in the detected components including any dependencies. CodeSentry continuously tracks these vulnerabilities throughout the software lifecycle.[6] The SBOM can be embedded along with each application making audit requests more reliable.
The NTIA has been tasked to define the minimum requirements of an SBOM[7] which includes the following:
- Author Name: The author of the SBOM, usually the organization supplying the software.
- Supplier Name: The name of the software supplier and should include aliases. Supplier and author might be different if the supplier is making a claim on behalf of the author.
- Component Name: The name of the software component and possible aliases.
- Version String: The format of the version information is free form but should follow common industry usage.
- Component Hash: The best way to identify a component is the use of a cryptographic hash that acts like a unique identifier. The specifics of these are usually defined by the interchange formats agreed upon by the industry.
- Unique Identifier: A unique identifier is needed for each component.
- Relationship: The relationship field defines the relationship between the component and the software package. In most cases, this relation is “includes” as in software package X includes component Y.
CodeSentry includes vulnerability information with each component in addition to the above list. These include:
- Component Match: This is the degree of confidence from the matching algorithm used by CodeSentry. Since the SBOM is automatically generated from binary code, matching to known components does have some degree of error.
- Security score: Based upon identified components and discovered vulnerabilities ranked by criticality, a security score is generated to highlight the risk of the software application.
- Path: The file path of the component.
- CVE Distribution: The distribution of discovered vulnerabilities by criticality (critical, high, medium and low.)
Security Vulnerability Report
CodeSentry creates a vulnerability report as part of the SBOM generation which identifies vulnerabilities in the components. These vulnerabilities are uniquely identified and include descriptive information:
- Severity: The vulnerability severity from its CVE entry based upon CVSS scoring.
- CVSS score: The common vulnerability scoring system value, between 0.0 and 10.0, which is used to prioritize vulnerabilities. The higher the score, the more likely the vulnerability is to be exploitable, have a large impact and inflict damage in a large area of the application or product. Critical vulnerabilities are in the 9.0-10.0 range.
- CVSS version: The CVSS has been updated over time so the version is important when looking at vulnerabilities with the same score.
- CVE ID: The unique identifier for a vulnerability’s entry in the national vulnerability database.
- Description: The text description provided by the CVE entry.
Supported Binary Formats and Languages
Instruction Set Architectures: x86-32, amd64, ARM
Languages: C; C++; Objective-C
Compression / Archive / Installation Formats: Zip (.zip); 7-Zip (.7z); Tar (.tar); Bzip (.bz2); Gzip (.gz); Windows Installer (.msi)
Binary Formats: Native binaries; Linux: executables, objects, archives, libraries (.o, .so, .a); Windows: executable, objects, libraries (.exe, .obj, .dll); Mac: executables, objects, libraries
References
- ↑ "GrammaTech Introduces CodeSentry™ to Identify Security Blind Spots in Third Party Code". Bloomberg.com. 2020-10-27. Retrieved 2021-09-09.
- ↑ Kashyap, Vineeth; Brown, David Bingham; Liblit, Ben; Melski, David; Reps, Thomas (2017-06-08). "Source Forager: A Search Engine for Similar Source Code". arXiv:1706.02769 [cs.SE].
- ↑ Katz, Deborah S.; Ruchti, Jason; Schulte, Eric (2018-03-01). "Using recurrent neural networks for decompilation". 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER): 346–356. doi:10.1109/SANER.2018.8330222. ISBN 978-1-5386-4969-5. Unknown parameter
|s2cid=ignored (help) - ↑ "Open-source software vulnerabilities". Aerospace Manufacturing and Design. Retrieved 2021-09-09.
- ↑ NTIA (November 16, 2020). "SBOM FAQ" (PDF). NTIA. Unknown parameter
|url-status=ignored (help) - ↑ "GrammaTech Discovers Vulnerabilities in Third-Party Code". DevOps.com. 2020-10-27. Retrieved 2021-09-09.
- ↑ NTIA (July 12, 2021). "NTIA Releases Minimum Elements for a Software Bill of Materials". Unknown parameter
|url-status=ignored (help)
External links
This article "CodeSentry" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:CodeSentry. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
