今日已更新 264 条资讯 | 累计 23847 条内容
关于我们

标签:#ann

找到 39 篇相关文章

AI 资讯

Monorepo Dependency Security — Vulnerability Scanning Across Packages

A monorepo can look like one repository, but security teams should treat it as many applications living under one roof. One repo may contain 10 frontend packages, 5 backend services, 3 shared utility libraries, 2 mobile apps, and one root lockfile that does not tell the full story by itself. Monorepo dependency security means scanning the root dependency graph, every workspace package, shared libraries, lockfiles, and generated SBOMs. If you scan only one file, you may miss the vulnerable package that ships in production. Why Monorepos Create Unique Vulnerability Challenges Monorepos centralize multiple packages, apps, services, and libraries inside one repository. This improves code sharing, dependency alignment, refactoring, CI caching, and cross-team collaboration. It also creates a security problem: one repository can contain many different dependency trees, owners, deployment targets, and risk profiles. A typical JavaScript or TypeScript monorepo may include apps/web , apps/admin , apps/api , packages/ui , packages/auth , packages/logger , and packages/config . Each package may have its own package.json . Some packages are deployed to production. Some are internal libraries. Some are build-only tools. Some are used by every app. A vulnerability in one package can affect one app, many apps, or the whole repo depending on how dependency relationships are structured. The biggest issue is shared code. If packages/auth depends on a vulnerable version of jsonwebtoken , every application that imports packages/auth may be affected. If packages/ui uses a vulnerable utility such as lodash , every frontend app that consumes that UI package may inherit the same risk. If a build tool dependency is compromised, the risk may appear during CI/CD rather than runtime. Real CVEs show why this matters. CVE-2021-23337 affected lodash through command injection in template handling. CVE-2022-31129 affected moment through inefficient parsing that could cause denial of service. CVE-202

2026-06-25 原文 →
AI 资讯

1.4.10 Planner Hook: When It Fires, How to Use It

Everything from 1.4.1 through 1.4.9 happened inside a single function, standard_planner() . Building paths, costing them, searching for a join order, estimating cardinality from statistics: all of it runs inside that one function. Yet PostgreSQL does not call standard_planner() directly. It puts another function, planner() , one step ahead of it, and has planner() call standard_planner() . And planner() can be made to call some other function instead of standard_planner() . That replacement is what the planner hook enables. When pg_stat_statements measures per-query planning time, or pg_hint_plan rewrites a plan according to hints, it all goes through this hook. Let's look at how PostgreSQL provides a way to observe or change planning behavior without touching a single line of the core, and how external code plugs into it. All planner() does is check the hook The body of planner() is essentially this. if ( planner_hook ) result = ( * planner_hook ) ( parse , query_string , cursorOptions , boundParams ); else result = standard_planner ( parse , query_string , cursorOptions , boundParams ); planner_hook is a global function pointer. Its default value is NULL , in which case standard_planner() is called right away. A plain PostgreSQL build always takes this path: planner_hook is empty, so the incoming query goes straight to standard_planner() . The key here is the type of planner_hook . typedef PlannedStmt * ( * planner_hook_type ) ( Query * parse , const char * query_string , int cursorOptions , ParamListInfo boundParams ); This signature is identical, down to the character, to that of planner() and standard_planner() . It takes the same Query and returns the same PlannedStmt (the execution plan). So external code only has to write a planner function matching this type and store its address in planner_hook . Let's call this function, written by external code to register in planner_hook , a custom planner function. The moment its address is stored, every planning reque

2026-06-21 原文 →
AI 资讯

Rails GuardDog: Advanced Security Scanner for Rails Applications

Rails GuardDog: Advanced Security Scanner for Rails Introduction Today I'm excited to announce Rails GuardDog v0.1.0 — an open-source security scanner for Rails that goes beyond traditional tools like Brakeman. While Brakeman is excellent for catching basic Rails vulnerabilities, Rails GuardDog focuses on newer vulnerability classes that most tools miss: AI/LLM prompt injection, DoS/ReDoS patterns, supply chain attacks, and more. The Problem Modern Rails applications face new security challenges: AI/LLM Integration - How do you prevent prompt injection when integrating with ChatGPT, Claude, or Anthropic? ReDoS Attacks - Catastrophic backtracking in regex can bring down your app Supply Chain Attacks - Typosquatted gems that look like popular libraries IDOR Gaps - Objects accessible without proper authorization checks Advanced Secrets - Hardcoded API keys that Brakeman misses Rails GuardDog detects all of these. What is Rails GuardDog? Rails GuardDog is a lightweight gem that adds comprehensive security scanning directly to your Rails applications. 12 Security Checkers SQL Injection - String interpolation in queries XSS - Unescaped output in views CSRF - Disabled protection verification Mass Assignment - permit! vulnerabilities (fixes Brakeman #1942, #1918) Open Redirect - User input in redirects Hardcoded Secrets - API keys, tokens, passwords (always-on, fixes #1989) DoS/ReDoS - Unbounded queries, dangerous regex patterns IDOR - Object access without authorization AI/LLM Prompt Injection - User input flowing to LLMs Rate Limiting - Missing rack-attack configuration Supply Chain - Typosquatted gems using Levenshtein distance GraphQL - Missing field-level authorization Features 📊 Multiple report formats : Console, HTML, JSON 🔍 AST-based analysis : Uses parser gem for deep code understanding ⚡ Async support : Built-in Sidekiq integration 📈 Zero dependencies : Only requires parser and ast gems 🚀 Production-ready : Tested and battle-ready 📝 CWE/OWASP mappings : Every find

2026-06-06 原文 →