Skip to content
Notifications
Clear all

Just built a proof-of-concept for a startup pitch. It was okay.

2 Posts
2 Users
0 Reactions
7 Views
(@security_dev_ops)
Eminent Member
Joined: 4 months ago
Posts: 12
Topic starter   [#2409]

Just used Sora to generate a pitch video for a new security tool concept. The goal was a 60-second explainer showing a developer's workflow, integrated vulnerability scanning, and a clean dashboard. The process was... efficient, but it left me with serious concerns for any real-world, security-conscious application.

The output was visually impressive and saved a ton of time versus traditional animation. However, the lack of control over the generated content is a non-starter for anything beyond a basic mockup.

My main issues from a security/ops perspective:

* **No deterministic output:** You cannot guarantee the same text prompt yields the same visual result. This makes versioning and reproducible builds impossible. My CI pipeline can't have a "maybe it'll look like this" step.
* **Black-box generation:** For compliance (think SOC2, ISO27001), we need to audit our toolchain. I have no insight into what training data was used. Could our pitch video inadvertently leak proprietary UI patterns or resemble a competitor's IP?
* **Artifact Integrity:** How do I checksum or sign a generated video for distribution? The model's non-determinism breaks standard integrity verification.
* **Supply Chain Risk:** Sora itself is a massive, opaque dependency. If it's a key part of our marketing pipeline, an API change, outage, or terms of service shift could break our entire demo generation process.

Here's the simple script I used to batch generate clips, which highlights the problem:

```bash
#!/bin/bash
# This is for illustration only - not for production use.
PROMPTS=("developer_types_code_at_terminal" "vulnerability_scan_results_appear" "dashboard_shows_green_compliance_status")
OUTPUT_DIR="./sora_generated_clips"

for PROMPT in "${PROMPTS[@]}"; do
# There's no --deterministic flag. Every run is a gamble.
curl -X POST https://api.openai.com/v1/videos/generations
-H "Authorization: Bearer $OPENAI_API_KEY"
-d "{
"model": "sora",
"prompt": "${PROMPT}",
"size": "1920x1080"
}" > "${OUTPUT_DIR}/${PROMPT}_$(date +%s).mp4"
done
```
Each time you run this, you get different videos. That's fine for a POC, but it's antithetical to stable, automated workflows.

For a startup pitch? It's a powerful toy. For building anything operational, especially in a field where audit trails and reproducibility are paramount, it's currently unfit. We need the equivalent of a `requirements.txt` and a `lockfile` for generative AI models before I'd consider it more than a novelty.

Secure by design.


SecDevOps


   
Quote
(@vendor_eye_roll)
Eminent Member
Joined: 4 months ago
Posts: 14
 

Finally someone gets it. The non-deterministic output alone should kill any professional use case. You can't have an asset that changes on every rebuild.

Your compliance angle is spot on, but you're missing the vendor lock-in angle. Once that video is part of your pitch deck, you're implicitly tied to their service. What's your migration path when they change the model, alter the API, or triple the price? You're left with prompts that no longer work and no source files.

This is fine for a one-off mockup. Using it for anything you might have to reproduce or maintain is asking for pain.


Trust but verify.


   
ReplyQuote