What Does SOOS Access and Store?

soos has been designed to run to the upmost extent possible in your own ci/cd system and to storage the bare minimum data necessary to run scans other than manifest files and/or sbom files, we never inspect or store any code sca regardless of whether you initiate the scan locally, on a ci/cd system, through our github integration, or using the file upload capabilities, soos only ever receives the contents of manifest files and/or file hashes and names we never look at any files other than those listed under supported languages and formats docid\ xdtkutu5yphcv3 6fp2e3 manifest file contents are parsed and only the information necessary is retained, primarily this consists of package id, version, file name, and optional dependency hierarchies for lock files a temporary audit of the full manifest file is retained briefly to assist with support inquiries sbom when scanning sbom files, soos will parse the sbom to extract information such as package id, version, and license information which is then run through our analysis engine we also store the contents of the sbom indefinitely storing the sbom ensures that we can run continual scans to detect new threats, as well as allow the original sbom to be bundled with future exports, particularly when creating dependent sboms containers soos uses syft to inspect container instances and generate a list of component information for the container when scanning containers, soos will parse the syft output to extract information such as package id, version, and license information, which is then run through our analysis engine a temporary audit of the full syft output is retained briefly to assist with support inquiries dast dast inspects web endpoints, therefore the data that is stored is related to the url being scanned when issues are identified, soos uses information such as the http request and response payloads to create issues and will store metadata about the request and response for requests that do not trigger issues, we only store the url itself without any other details sast/secret detection the sast/secret detection allows you to bring your own sast or secrets tool and feeds the results into soos as a sarif file the results will then be presented alongside your other scan details for the project because we do not control the sast/secrets tool you select, we cannot make any guarantee about the data sent to soos we recommend you run the tool with the sarif output option and inspect the results yourself to ensure you are comfortable with the results being ingested by soos typically, there is no concern as the code examples these tools include are usually quite specific to the problem and only consist of a single line or two additional information sca (software composition analysis) clients provide dependency manifests (e g , packages config, pom xml, requirements txt, etc ) some may consider these “source code,” but in reality they’re not the intellectual property of your app, they’re simply the top level ingredient list much like the ingredients label on a can of coca cola, they list what’s inside (open source libraries) but don’t reveal the recipe or how the product is made we process these manifests in the cloud to build the dependency tree, identify vulnerabilities, and inventory oss licenses sast (static application security testing) soos sast is structured so that clients run an open source static analysis tool within their own environment against their source code that tool generates a standardized sarif results file, and our soos sast agent uploads only that sarif file to soos for further analysis no source code is ever transmitted transparency our sast and sca agents are open source and available on github ( sast agent , sca agent ), so clients can review exactly what runs in their environment and what is sent to soos please also find via this link cisa's faq on sboms, which covers some questions directly a software manifest, one of the key components that soos scans, is a common precursor to an sbom below is an excerpt from the section titled, "common misconceptions & concerns" , which includes cisa's responses to questions such as q "does an sbom require source code disclosure?" a no your proprietary source code remains yours to share or to keep confidential at your discretion concerns about exposing the internals of your code’s operation are likewise unfounded, as these software components are just “a piece of the puzzle”, not anything close to the “whole completed puzzle” that represents your program q "does a list of the software components i include expose my intellectual property?" a generally, no first, there is a big difference between knowing the third party ingredients and the ultimate recipe or execution further, any intellectual property associated with these supply chain components belongs to those upstream, third party, commercial and open source software suppliers in fact, the licenses those suppliers attached to their components may obligate you to publicly disclose that you include their software in any form some organizations attempt to claim the list itself is a trade secret your legal team is best poised to advise if you are able to meet the standard of this claim and avoid violation of previously mentioned competing license obligations in general, most open source and third party components do not reveal any intellectual property in some cases, there may be sensitive components with ip implications many find the use of “known unknowns” for specific component redactions meets their original intentions q "won’t sboms be a 'roadmap to the attacker'?" a theoretically, yes in reality, the defensive benefits of transparency far outweigh this common concern as sboms serve more as a “roadmap for the defender” all 7 information is dual edged, but insufficient software transparency affords attackers asymmetrical advantages first, attackers don’t need sboms; mass, indiscriminate attacks like wannacry serve to remind us that foreknowledge is not a prerequisite to cause harm second, attackers and their tools can more easily identify software components; conversely, it is often quite challenging, disruptive, inefficient, and even unlawful for defenders to determine the same third, attackers of any single product can already find human readable target components — licensing requirements have been increasingly requiring disclosure for decades sboms seek to level the playing field for defenders by providing additional transparency — at enterprise scale — with standard, machine readable decision support