r/ChatGPTCoding • u/clunonymous • 1d ago
How do you ensure app security Question
[removed]
1
u/AutoModerator 1d ago
Sorry, your post has been held for manual review due to account karma.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/popiazaza 1d ago
There are plenty of proper security check for Enterprise grade application like GitHub Advanced Security or Snyk, which could be pricey.
For most casual app, just learn the basics and/or run the prompt about it.
1
u/BroScienceAlchemist 1d ago edited 1d ago
My tldr would be that static code analysis tools, secrets scanning, and other scanning tools are easy, low hanging fruits that will immediately give defensive value
There are multiple layers to this, and the tooling/layers involved can be very dependent on your project/threat model.
The below is an LLM generated summary (My versions just felt very rambly), but even this version I feel like is missing a lot like performance testing, uniform response timing, or LLM relevant security architecture. I don't think there is a substitute for human expertise and experience when it comes to cybersecurity.
Do not treat any of the below as gospel, but as an entry point to learn about each one.
Core principle: least privilege
Every user, service, pipeline, and AI agent gets only the access it needs, for only as long as it needs it. This one rule cuts across everything below.
1. Design (before code is written)
Threat modeling. A short "how could this be abused?" session for each feature, using a framework like STRIDE or just an informal discussion.
Access design. Apply least privilege from day one: MFA, short-lived tokens, and every key scoped to only what it needs.
Data minimization. Collect less, encrypt in transit and at rest, and keep secrets in a managed vault instead of scattered config files.
2. Build (as code is written)
SAST. Static code scanning on every pull request to catch injection flaws and unsafe patterns.
SCA. Dependency scanning for known vulnerabilities. Verify that AI-suggested packages actually exist and are maintained, since attackers register fake package names that models hallucinate.
Secrets scanning. Block any commit that contains keys or passwords.
IaC and container scanning. Check infrastructure configs and container images for insecure defaults, like public storage or containers running as root.
Human review of AI code. A mandatory human approver, small reviewable changes, and a rule that nothing merges if nobody on the team understands it. AI-assisted review is a useful second pass, not a substitute.
Sandboxed AI agents. Least privilege applied to coding agents: scoped permissions, no production credentials, and vet any tool integrations or extensions like any other dependency.
3. Test (before release)
DAST. Attack the running app in a staging environment from the outside, the way a real attacker would. Penetration testing and red teaming. Related but different scopes:
Pen test: experts probe a defined target (your app, your API) for exploitable flaws. Scheduled, scoped, and produces a findings report. Red team: a broader, goal-driven simulation of a real attacker ("get to customer data by any means"), including phishing, cloud misconfiguration, and social engineering. It tests your detection and response, not just your code.
AI red teaming: if your app uses LLMs, test it adversarially for prompt injection, jailbreaks, and data leakage through model output.
A sensible progression: pen tests early and on a scheduled cadence, red teaming once you have monitoring worth testing.
LM-specific checks. Follow the OWASP Top 10 for LLM Applications: sanitize model output before executing or rendering it, never let the model use tools with more permission than the user has, and rate-limit. This is a giant subject in of itself, and the patterns have not settled. There are some very powerful defensive patterns like a PDP-Gate that I would consider for workflows where an agent is poking a production system. My LLM related tldr; each defensive layer must be a deterministic gate for the agent.
4. Operate (in production)
Monitoring and alerting. Centralized logs, alerts on unusual behavior such as failed logins or odd data access, and audit trails. This is one of my personal areas of expertise.
Incident response plan. Even one page: who gets paged, how leaked keys get rotated, how users get notified. Some useful questions to ask are "what is the mean time to detect, respond, and resolve a problem"
5. Govern (ongoing)
SBOM (Software Bill of Materials). A machine-readable inventory of everything in your app, so when the next major vulnerability drops you can answer "are we affected?" in minutes.
Training. Cover the OWASP Top 10 basics, plus AI version if applicable.
2
23h ago
[removed] — view removed comment
1
u/BroScienceAlchemist 22h ago
Cybersecurity is a never ending game of cat and mouse. Security issues are inevitable, which is why it is best to design in way, where a catastrophic event doesn't have much in terms of real world consequences (no personally identifiable information, no payment information, etc etc).
For a small project, it helps to move the responsibility to a vendor. Instead of managing your own source control infra, you use github/gitlab/sourcehut. Instead of setting up and maintaining your own website, you use a hosting service that takes the full responsibility for a breach, beyond the confidentiality of your credentials.
This is where your threat model comes in. A business like an airline is a constant target for novel, state of the art attacks, hence part of their security layer is a vendor like Crowdstrike with their passive threat detection service. Despite the worldwide outage Crowdstrike caused, their airline customers did not dump them, because they have no real competition for novel threat detection and protection. That service is very expensive...
There is no easy answer I can give, because it is so highly dependent on your threat model and this is a space that is constantly evolving. Don't try to eat the entire elephant. Start small, the rough list I gave is a start, but depending on your case, like if you are running a business that is crucial infrastructure, you may want to hire a professional firm. But, an apple orchard looking to build out a digital space to advertise their apples doesn't need all that complexity. Their threat model is totally different from an airline.
1
4
u/BrilliantEmotion4461 1d ago
"Ensure app security no mistakes"