Add GCP and Auth0 security skills

[Ayush7614]

Summary

Adds two skills from underrepresented categories in the skills README:

• cloud/gcp — GCS public buckets, IAM escalation, metadata server abuse, GKE/Cloud Functions misconfigs
• technologies/auth0 — Auth0 tenant config, callback/origin flaws, Rules/Actions claim injection, MFA bypass, org boundaries

Why these skills

• README lists AWS, Azure, GCP under /cloud — only aws and kubernetes existed
• README lists Auth0 under /technologies — only Supabase and Firebase existed
• Complements merged PR Add five security skills: OAuth, AWS, prototype pollution, deserialization, Django #617 (aws, oauth, django) without overlapping open skill PRs

Verification

uv run python -c "
from strix.skills import get_all_skill_names, load_skills, validate_requested_skills
for s in ['gcp', 'auth0']:
    assert s in get_all_skill_names()
    assert validate_requested_skills([s]) is None
    assert '## Validation' in load_skills([s])[s]
print('OK')
"

Test plan

• Skill discovery and validation passes locally
• Maintainer review of technical accuracy

[greptile-apps]

Greptile Summary

This PR adds new security skill documentation for GCP and Auth0. The main changes are:

• A new cloud/gcp skill covering GCS, IAM, metadata, GKE, and serverless misconfigurations.
• A new technologies/auth0 skill covering tenant settings, callbacks, token validation, MFA, and organizations.
• Frontmatter and markdown sections for skill discovery and prompt loading.

Confidence Score: 4/5

The new skill files are mostly mergeable after fixing the misleading security-testing examples.

• Skill discovery and loading appear compatible with the existing filename-based loader.
• The GCP bucket guidance can report the wrong public-access result when local credentials are present.
• The Auth0 userinfo example can confuse an expected authenticated response with public discovery behavior.

strix/skills/cloud/gcp.md and strix/skills/technologies/auth0.md

Security Review

The new files are security testing guidance. The GCP public-bucket check can misclassify private buckets as public when ambient credentials are present, and the Auth0 userinfo example omits the required bearer token.

Important Files Changed

Filename	Overview
strix/skills/cloud/gcp.md	Adds a GCP skill that should load correctly, but its unauthenticated GCS listing example can use ambient credentials.
strix/skills/technologies/auth0.md	Adds an Auth0 skill that should load correctly, with one endpoint example that needs its authentication requirement shown.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
strix/skills/cloud/gcp.md:42
**Ambient Credentials Skew Public Checks**

When this command runs on a machine with `gcloud` or application-default credentials, `gsutil` can list buckets with the tester's own access while the section claims to test unauthenticated exposure. That can turn a private bucket into a false public-bucket finding, or hide that the anonymous test was never performed.

```suggestion
# Anonymous listing check; avoid gsutil here because it can use ambient credentials
curl https://storage.googleapis.com/target-bucket/
```

### Issue 2 of 2
strix/skills/technologies/auth0.md:43
**Userinfo Requires A Token**

`/userinfo` is grouped with public discovery endpoints, but a correctly configured Auth0 tenant returns `401` unless the request includes a bearer access token. A tester following this literally can treat the expected auth failure as an OIDC discovery result instead of validating the authenticated userinfo path.

```suggestion
GET https://TENANT.auth0.com/userinfo
Authorization: Bearer <access_token>
```

_{Reviews (1): Last reviewed commit: "Add GCP and Auth0 security skills" | Re-trigger Greptile}

[greptile-apps]

Ambient Credentials Skew Public Checks

When this command runs on a machine with gcloud or application-default credentials, gsutil can list buckets with the tester's own access while the section claims to test unauthenticated exposure. That can turn a private bucket into a false public-bucket finding, or hide that the anonymous test was never performed.

Suggested change

	gsutil ls gs://target-bucket
	# Anonymous listing check; avoid gsutil here because it can use ambient credentials
	curl https://storage.googleapis.com/target-bucket/

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/cloud/gcp.md
Line: 42

Comment:
**Ambient Credentials Skew Public Checks**

When this command runs on a machine with `gcloud` or application-default credentials, `gsutil` can list buckets with the tester's own access while the section claims to test unauthenticated exposure. That can turn a private bucket into a false public-bucket finding, or hide that the anonymous test was never performed.

```suggestion
# Anonymous listing check; avoid gsutil here because it can use ambient credentials
curl https://storage.googleapis.com/target-bucket/
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Userinfo Requires A Token

/userinfo is grouped with public discovery endpoints, but a correctly configured Auth0 tenant returns 401 unless the request includes a bearer access token. A tester following this literally can treat the expected auth failure as an OIDC discovery result instead of validating the authenticated userinfo path.

Suggested change

	GET https://TENANT.auth0.com/userinfo
	GET https://TENANT.auth0.com/userinfo
	Authorization: Bearer <access_token>

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/technologies/auth0.md
Line: 43

Comment:
**Userinfo Requires A Token**

`/userinfo` is grouped with public discovery endpoints, but a correctly configured Auth0 tenant returns `401` unless the request includes a bearer access token. A tester following this literally can treat the expected auth failure as an OIDC discovery result instead of validating the authenticated userinfo path.

```suggestion
GET https://TENANT.auth0.com/userinfo
Authorization: Bearer <access_token>
```

How can I resolve this? If you propose a fix, please make it concise.

[Ayush7614]

cc: @rajpratham1