T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/ontology.py:112- Finding
Graph Mutations Bypass Schema Validation Before Persistence
- Content
View full analysis
dict: """Create a new entity.""" entity_id = entity_id or generate_id(type_name) timestamp = datetime.now(timezone.utc).isoformat() entity = { "id": entity_id, "type": type_name, "properties": properties, "created": timestamp, "updated": timestamp } record = {"op": "create", "entity": entity, "timestamp": timestamp} append_op(graph_path, record) return entity ``` The command dispatcher also invokes mutation functions directly after parsing JSON, without loading the schema or calling `validate_graph()`: ```python if args.command == "create": props = json.loads(args.props) entity = create_entity(args.type, props, args.graph, args.id) print(json.dumps(entity, indent=2)) ``` ### Technical Analysis The Skill documentation states that every mutation is validated against type constraints before being committed. The implementation instead appends create, update, and relation operations directly to the persistent JSONL graph. `validate_graph()` is only available through a separate, post-hoc `validate` command and does not roll back invalid records. Consequently, callers can persist: - Entities missing required properties. - `Credential` entities containing forbidden properties such as `password`, `secret`, or `token`. - Unknown or unrestricted entity types. - Duplicate entity IDs that replace the effective in-memory representation when the graph is loaded. - Properties whose JSON value is not an object, potentially causing later operations to fail. - Relations whose source or destination does not exist. - ...[truncated 1917 chars]- Remediation
View remediation