SBOM/OSS utilization development support
In recent years, it is included in software called SBOM (Software Bill of Materials) in order to prevent damage due to license and vulnerability risks associated with the expansion of open source software (OSS) utilization in software development, and to fulfill accountability and regulatory compliance. There is a need in various fields, including the automobile and medical industries, to develop a bill of materials that can manage OSS.
At Covalent, we formulate OSS management plans and specialize in designing optimal SBOM tools and operation systems that suit our customers. In addition, it is also possible to act as an agent for SBOM operation on behalf of customers who find it difficult to secure SBOM operation personnel.
Our company has experience in participating in the Ministry of Economy, Trade and Industry's SBOM demonstration, experience in SBOM operation work, and knowledge of the latest SBOM utilization overseas. Free diagnosis is also available for those who do not know what to do about OSS management.
If you want to understand the details of the service such as the output image, please request detailed materials from the following.
Partnership
partnership
We can introduce all major overseas SBOM tools.
ISSUES
Issue
-
In the first place, I do not know what SBOM is and whether it is necessary for my company
-
I understand that it is necessary to introduce SBOM for WP29 compliance, but I do not know the specific details of the necessary work
-
I would like to know about the efforts of other overseas companies in the same industry regarding SBOM.
-
I don't know the schedule of SBOM introduction
Concerns about SBOM tool introduction and operation construction
-
I don't know what to do with the operational design of the SBOM tool
-
I don't know how to change the contract with OEM/supplier and how to negotiate with SBOM.
-
SBOM tools have been introduced, but they are not used at all because they do not know how to use them or do not have time to use them.
Concerns about considering introduction of SBOM
Concerns about selecting SBOM tools
-
I don't know which of the many SBOM tools is better
-
In the first place, it is impossible to define the requirements for the company's SBOM tool, and there is no way to evaluate the tool.
-
I don't have time to actually try the SBOM tool and make an evaluation selection
SERVICE MENU
service menu
Introduction plan formulation support
First, we organize the implementation guidelines based on the customer's OSS management-related laws, standard requirements, and needs. Based on this, we design activities to fill the gap between the customer's necessary SBOM operation, OSS security and compliance response, and the current situation of the customer, and establish the deadline for each country's laws and international standards, OEM response, and other companies' case studies. We will design the SBOM introduction schedule based on the SBOM introduction timeline etc.
PoC and selection support for SBOM tools
We formulate evaluation and selection criteria for SBOM tools based on the customer's development environment, business partner's requirements, and related laws and regulations. Plan and execute a PoC of the SBOM tool to obtain the necessary information for evaluation. Based on the evaluation selection criteria and PoC results, we select the optimal SBOM tool. In addition, we have a track record of using all major SBOM tools.
SBOM tool introduction and operation construction support
Set up the selected SBOM tool so that it can be operated. Specifically, we develop operational tasks, division of roles, operational rules, and an operational system that match the selected SBOM tool. We will also appropriately reflect the clauses necessary for SBOM operation that are included in contracts with business partners. If it is difficult to secure personnel to handle SBOM in-house, we can also provide operation support services for OSS component management, vulnerability and license management through SBOM operation at our company.
APPROACH
approach
Introduction plan formulation support
1
1
Government and regulatory information research
about a week
List laws and regulations related to domestic and overseas OSS management, vulnerability and license management, and response, and organize the obligations and scope of responsibility stipulated therein.
Output: Survey results of relevant laws and regulations
2
Benchmark survey of other companies
About 1 month~
Scope of responsibility/responsibility and operation rules for OSS management, vulnerability/license management/response in cases of other companies (e.g. detection timing/update frequency, criteria for judging whether or not to respond when vulnerability/license violation is detected, standard response time) etc.), the output format of each work, OSS management, vulnerability and license management, SBOM tools and collaboration tools used for response, and issues and solutions that have occurred.
Output: Results of research on precedents
3
Contract system maintenance support
about 2 weeks
In the contract between OEM/Tier1/Tier2, OSS/vulnerability/license detection and obligations at the time of vulnerability/license violation, implementation body of OSS detection/vulnerability management/license management for development scope, and responsible body (monetary) We will prepare a contract scheme for the person who bears the burden and legal responsibility). Diagnose the estimated loss amount due to inadequate handling of vulnerabilities and license violations, and estimate and summarize the potential impact of compliance risks and cyber security incidents from similar cases (final checks are also performed by lawyers specializing in security-related laws and regulations).
Output: Arrangement of contract scheme (economic conditions, roles and responsibilities)
Four
SBOM standards and system design
about 2 weeks
Based on other companies' benchmarks, various laws and regulations, international standards, and requirements for OEM suppliers, we design activities to fill the gap between the customer's current situation and the SBOM operation and OSS security compliance required by the customer.
Output: Outline of SBOM operation rules
Five
Introduction schedule design
about 2 weeks
We design the SBOM introduction process and schedule for customers based on the laws and regulations of each country, international standards, OEM deadlines, and SBOM introduction timelines in other companies' cases. In addition, we organize the type and period of PoC required for introduction to the customer.
Output: Overall picture of SBOM introduction schedule and PoC implementation schedule
PoC and selection support for SBOM tools
1
Requirement definition of SBOM tool in customer
about a week
Based on the customer's development SW, development process/environment (e.g. access to source code), related laws/regulations/requirements from business partners, customer budget, etc., we define the requirements for the SBOM tool to be introduced by the customer.
Output: Requirement definition result
2
Narrow down SBOM tool candidates for PoC
from 1 month
Based on the requirement definition, we will research possible SBOM tool candidates and present promising options.
Output: SBOM tool candidate
3
Formulation of PoC plan
from 1 month
Based on the requirements definition, we formulate the items that need to be verified and the verification method in the PoC of the SBOM tool for the tool evaluation selection criteria and selection. We will also organize the customer data requirements necessary for PoC implementation.
Output: PoC execution plan
1
Four
PoC execution
from 1 month
Execute the PoC according to the formulated plan. It is also possible to provide hands-on support where our company handles negotiations with tool vendors and work at the time of PoC.
Output: PoC execution result
Five
SBOM tool selection based on PoC results
about 2 weeks
After organizing the PoC results, we select the most suitable tool for the customer based on the evaluation selection criteria.
Output: SBOM tool selection results
PoC and selection support for SBOM tools
1
SBOM tool setup
about a week
We set up an SBOM tool with reasonable functions/performance and introduction/operation cost for customer's OSS management. pop up. Also set up the development tools that need to be linked with the SBOM tool.
Output: Preparation for introduction of SBOM tools
2
SBOM operation work and design of division of roles
about a week
After defining the tasks required for SBOM operation and taking legal compliance into account (e.g. OSS detection ⇒ correction of false detections and omissions ⇒ …), we design the roles necessary for operational tasks.
Output: Overview of SBOM operations and division of roles
3
Designing SBOM operational rules
about a week
Design detailed rules related to SBOM operation. OSS/vulnerability/license detection/responsibility/range of responsibility, timing/frequency of work execution, standard response time for OSS/vulnerability/license detection/response, criteria for judging the necessity of response when vulnerability/license violation is detected, etc. Consider.
Output: Details of SBOM operational rules
Four
Design of SBOM operation system
about a week
Design departments, positions, and personnel in charge of each role necessary for operations, and rules for cooperation between personnel (eg, escalation rules when detecting vulnerabilities and license violations).
Output: Details of SBOM operation system
Five
Contract system with business partners
about 2 weeks
Regarding SBOM operation, we clarify the division of work with OEMs and suppliers, the location of financial burdens and legal responsibilities, and support their reflection in contracts.
Output: contract system and contract
1
ADVANTAGE
advantage
Based on the Ministry of Economy, Trade and Industry's SBOM demonstration experience, PoC of appropriate SBOM tools is possible.
We can design an appropriate PoC evaluation axis based on the customer's business and business conditions.
We can propose realistic SBOM operation by combining our experience of actual operation of SBOM and our knowledge of embedded software development in the automotive industry.
Utilizing the resources of our partners, it is possible to act as an agent even if the SBOM operation becomes large-scale.
OUTPUT
Output
OSS list by SBOM scan
Organize the list of OSS included in your software product using the SBOM tool.
If necessary, we will also confirm with the business partner on your behalf and create an accurate OSS list.
Construction of OSS management system
We build rules and operational systems to deal with vulnerability risks and compliance risks for the OSS included in the customer's product. We will also sort out the content to be implemented in-house and the scope of requests to external collaborators.
OSS operation support
We will operate OSS on behalf of customers who do not choose to respond on their own due to various reasons such as not being a main business or lacking expertise. In addition to providing weekly reports, in the event of an emergency, we will contact you immediately and continue to support you until the problem is resolved.
TRACK RECORD
achievement
KPIs
Number of client industriesFourIndustry
Percentage of clients with multiple contracts Approx.95.5%
Percentage of Projects with Benefits100%
Average contract period Approx.6for a month
Number of SBOM tools handled11type
Number of specialist members Approx.9Name
CASE STUDY
 自動運転開発ツール自動運転開発ツールを提供する企業におけるOSS管理と運用体制を設計。SBOMツールの導入支援も実施。 |  OSS管理体制の設計自動車部品サプライヤにおけるOSS管理に向けた開発管理体制を設計。担当者の設定とツール導入、マニュアル整備を担当。 |  OSS管理の運用支援オンラインゲームにおけるOSSを管理し、バージョンアップデートに伴うライセンス違反や脆弱性データのモニタリングを実施。 |
|---|---|---|
 Coming SoonComing Soon |  Coming SoonComing Soon |
CLIENTS' VOICE
customer's voice
Major auto parts manufacturer
Proposals based on proven cases overseas were helpful
While there are still very few achievements in Japan, the proposals based on the cases of major overseas competitors were very useful. It was especially helpful when it was hard to tell if I was doing too much.
In addition, when reporting to management, most of the materials were compiled, and they contributed greatly as consulting.
Major software development company
I felt the convenience of leaving the operation to a third party
At first, some members thought that entrusting the inventory and management of software assets to a third party was too risky, but I felt that it was very meaningful to have the OSS correctly identified and the work including confirmation with the vendor. I was.
It was a natural flow to leave the operation after that, but I was able to entrust it without any problems because I was able to proceed with the internal coordination, which was a high hurdle, and I am very grateful. increase.