My Tech, My Rules: AI, WASM, SBOM, and Your Personal Policy

Understanding SBOM: Inventory and Single Source of Truth

A Software Bill of Materials (SBOM) provides a clear inventory of everything inside a piece of software, including the names and versions of its dependencies (source). This inventory functions as a single source of truth for what components constitute the software (source).

In my view, having an explicit list of dependencies allows teams to answer basic questions about what code is present, which is a prerequisite for any further analysis of security, licensing, or operational risk. When the inventory is accurate and up‑to‑date, stakeholders can trace a specific version of a library back to its origin, a capability that the source describes as the SBOM acting as a “single source of truth”.

The concept of a single source of truth is often invoked in data management to reduce ambiguity. Applied to software, it means that rather than relying on disparate build logs, package manager lock files, or memory‑based recollections, an organization can consult one authoritative document that enumerates each dependency. This aligns with the statement that the SBOM “gives you a clear inventory of everything inside your software”.

While the source does not elaborate on downstream effects such as vulnerability patching or license compliance, the logical extension is that an accurate inventory enables those processes. I note that this extension is an inference drawn from the provided fact and not a claim made directly by the source.

Practically, generating an SBOM can be integrated into continuous integration pipelines so that each build produces an up‑to‑date inventory. This practice mirrors the source’s emphasis on clarity and truthfulness, ensuring that the artifact reflecting the software’s composition evolves alongside the code itself.

Black Duck and Supply Chain Scrutiny

Black Duck scrutinizes the entire software supply chain, identifying license risks, security flaws, and malicious packages with precision and speed (source).

This capability means that, given a codebase, Black Duck can analyze the components it contains (potentially using an SBOM as input) and flag any that violate licensing policies, contain known vulnerabilities, or have been identified as malicious (source).

In my interpretation, the combination of an SBOM (which supplies the inventory) and a tool like Black Duck (which evaluates that inventory) creates a workflow where the supply chain is first made visible and then assessed for risk. The source does not specify the exact algorithms or data sources used, but it does assert the outcome: identification of license risks, security flaws, and malicious packages.

From a policy perspective, an individual or organization could adopt a personal rule that any third‑party code must pass through such scrutiny before being incorporated. This rule would be grounded in the factual claim that Black Duck can detect the mentioned issues with precision and speed.

It is worth noting that the source does not claim that Black Duck eliminates all risk; it merely states that it identifies the listed issues. Therefore, a personal policy might also include residual risk acceptance criteria, acknowledging that detection is necessary but not sufficient for complete safety.

WebAssembly (WASM) for Microservices and Serverless

A Reddit discussion questions whether anyone is running microservices using WebAssembly (WASM), hinting at interest in the technology for lightweight, serverless‑style functions (source).

Complementing that, a dev.to article dated April 15, 2025, describes WebAssembly in DevOps as “the next big thing” and lists specific use cases: microservices—deploying lightweight services with minimal overhead—and serverless computing—improving cold start performance (source).

According to these sources, WASM enables the creation of services that are lightweight (low resource footprint) and can be started quickly, which is advantageous for serverless platforms where cold start latency impacts user experience.

In my view, the appeal of WASM for microservices lies in its sandboxed execution model and near‑native performance, which together allow developers to package functionality in a portable binary that can run across diverse environments without the overhead of a full container or virtual machine. The source’s mention of “minimal overhead” and “improve cold start” directly supports this perspective.

When considering a personal tech policy, one might decide to evaluate WASM as a candidate for any new service that demands rapid scaling or strict resource constraints. The decision would be informed by the factual claims about lightweight deployment and cold‑start improvement cited above.

It is important to recognize that the sources do not guarantee that WASM will be suitable for every workload; they merely highlight particular advantages observed in certain contexts. Therefore, a personal rule could include a performance‑evaluation step before adopting WASM for a given microservice.

Personal AI Policy: Lessons from the Hank Green Controversy

The Vox article highlights that everybody needs a personal AI policy, using Hank Green as an example (source). It notes that Hank Green acknowledged using AI for research and stated that he had been “relying too heavily on AI as a research” (source).

This situation illustrates a scenario where the use of AI assisted a knowledge‑worker, but the reliance on AI raised concerns about originality, attribution, and the depth of personal understanding.

In my opinion, a personal AI policy could delineate the circumstances under which AI tools are permitted, the extent of their use (e.g., idea generation vs. drafting full text), and mechanisms for verifying AI‑generated content. The Hank Green example underscores the risk of over‑reliance, suggesting that a policy might include limits on the proportion of work that may be AI‑produced.

The source does not prescribe a specific policy format; it merely asserts the need for one and provides a concrete case where the lack of clear boundaries led to public discussion. Therefore, any specific rules I propose would be derived from interpreting that need, not from direct instructions in the source.

Additionally, the controversy hints at broader ethical considerations such as transparency about AI use and the potential impact on credibility. A personal policy might therefore incorporate a disclosure clause, stating when and how AI assistance will be communicated to audiences or collaborators.

AI Knowledge Siphoning: The Chinese Firm and Anthropic Claude Case

Forbes reported that a Chinese AI firm siphoned American AI knowledge from Anthropic’s Claude model by using millions of prompts, a practice described to Congress as having ripped‑off digital knowledge from Claude (source).

The factual claim centers on the volume of interaction (millions of prompts) and the outcome (the firm allegedly extracted knowledge that it then used to train its own models). The source frames this as a modern‑era cold‑war tactic.

From a personal‑policy standpoint, this case raises questions about how individuals protect their own interactions with AI services. If one regularly prompts a large language model, the pattern of those prompts could, in theory, be harvested to infer proprietary or sensitive information.

In my view, a personal AI policy might include guidelines on prompt hygiene: avoiding the inclusion of confidential or proprietary details in prompts, limiting the repetition of similar queries that could reveal patterns, and periodically reviewing the data‑retention policies of the AI provider. These measures are extrapolations from the fact that massive prompt volumes can be used to siphon knowledge.

The source does not discuss mitigation strategies; it only documents the occurrence. Consequently, any protective steps I suggest are interpretive rather than directly cited.

Furthermore, the case illustrates the broader theme that AI models can be indirect vectors for knowledge transfer. A personal policy could therefore treat interactions with AI as potentially exposed channels and apply the same caution one would use when sharing information over any networked service.

Bringing It Together: Crafting Your Personal Tech Policy

Having examined the four factual domains—SBOM inventory and single source of truth (source), Black Duck’s supply‑chain scrutiny (source), WASM’s suitability for lightweight microservices and serverless (source, source), and the AI‑related considerations from the Hank Green controversy (source) and the Claude knowledge‑siphoning incident (source), we can synthesize a personal tech policy that addresses visibility, risk assessment, technology choice, and responsible AI use.

Visibility and Inventory: Maintain an up‑to‑date SBOM for all software you develop or deploy. Treat this SBOM as the single source of truth for what components are present (source). This enables informed decisions about updates, licensing, and security.

Risk Assessment: Subject the inventory to automated scrutiny using tools analogous to Black Duck to identify license risks, security flaws, and malicious packages (source). Incorporate this step into your continuous integration pipeline so that each build is evaluated before release.

Technology Selection: When considering new runtimes or deployment models, evaluate WebAssembly for microservices or serverless functions if low overhead and fast start‑up are priorities (source). Use the Reddit discussion as a reminder that community adoption is growing (source), but validate suitability through performance testing specific to your workload.

AI Use Governance: Adopt a personal AI policy that specifies permissible uses of generative AI, sets limits on over‑reliance (source), and includes prompt‑hygiene practices to mitigate knowledge‑siphoning risks (source). Consider disclosure statements when AI contributes significantly to produced work.

Review and Iteration: Treat the policy as a living document. Revisit it when new facts emerge—for example, updates to SBOM standards, fresh WebAssembly performance benchmarks, or changes in AI provider terms—to ensure it remains aligned with the current technological landscape.

Conclusion: My Tech, My Rules

The intersection of software transparency, runtime innovation, and AI ethics forms a fertile ground for personal governance. By grounding each rule in verifiable facts—such as the inventory function of an SBOM (source), the supply‑chain analysis offered by tools like Black Duck (source), the lightweight and cold‑start advantages of WebAssembly for microservices and serverless (source, source), and the cautionary tales of AI overuse and knowledge extraction (source, source), you can construct a robust, personalized framework that guides your technical decisions.

Ultimately, “My Tech, My Rules” is not a static manifesto but a habit of continual verification, risk assessment, and thoughtful adoption. When each choice is traced back to a concrete, sourced fact, the resulting practice is both defensible and adaptable—exactly the blend needed to navigate today’s fast‑moving technological environment.