This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-02-07
Channels
- # aleph (4)
- # announcements (9)
- # babashka (44)
- # beginners (6)
- # cider (8)
- # clj-kondo (5)
- # clojars (10)
- # clojure (10)
- # clojure-berlin (1)
- # clojure-dev (9)
- # clojure-europe (20)
- # clojure-gamedev (1)
- # clojure-miami (2)
- # clojure-nl (1)
- # clojure-norway (21)
- # clojure-uk (5)
- # clojurescript (12)
- # conjure (1)
- # cursive (19)
- # data-science (2)
- # datahike (10)
- # etaoin (5)
- # events (3)
- # fulcro (14)
- # gratitude (2)
- # honeysql (8)
- # humbleui (1)
- # hyperfiddle (60)
- # introduce-yourself (7)
- # jobs-discuss (27)
- # juxt (2)
- # kaocha (7)
- # lsp (23)
- # malli (9)
- # missionary (2)
- # off-topic (48)
- # pathom (24)
- # releases (1)
- # shadow-cljs (256)
- # sql (46)
- # xtdb (19)
https://github.blog/changelog/2023-04-28-secret-scanning-now-supports-validation-checks-for-supported-partner-patterns/ Clojars doesn’t support this yet, but I think we could
Interesting. It looks like this sends the token to the corresponding partner, and asks if it is a valid token. But it's not clear to me why the token would not already be considered leaked since it is in a repo? Or is the secret scanning more nuanced than that?
I think the idea is that it can help teams prioritise leaked tokens in private repos
So if someone has published an AWS key in a private repo, the secret scanning can check it to say whether the key is valid or not, so then the security team can prioritise/deprioritise fixing it
I think it only comes into play for private repo scanning. On a public repo it would be considered leaked and then revoked automatically by the partner
Gotcha. It looks like they recommend revoking any token sent (https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/secret-scanning-partner-program#implement-secret-revocation-and-user-notification-in-your-secret-alert-service). The validity feature is handled by the payload we return (https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/secret-scanning-partner-program#provide-feedback-for-false-positives). It would be very easy for us to extend what we have now to return the validity.
I think it would just be:
modified src/clojars/routes/token_breach.clj
@@ -36,25 +36,35 @@
(base64/decode key-sig)
{:key key :alg :ecdsa+sha256}))))
-;; - make emails async
;; - add timing logs
+(defn- token-response
+ [{:keys [token type]} found?]
+ {:token_raw token
+ :token_type type
+ :label (if found? "true_positive" "false_positive")})
+
+(defn- check-token
+ [db event-emitter {:as token-data :keys [token url]}]
+ (if-some [{:as db-token :keys [id disabled user_id]}
+ (db/find-token-by-value db token)]
+ (do
+ (when (not disabled)
+ (db/disable-deploy-token db id))
+ (event/emit event-emitter :token-breached
+ {:user-id user_id
+ :token-disabled? disabled
+ :token-name (:name db-token)
+ :commit-url url})
+ (token-response token-data true))
+ (token-response token-data false)))
+
(defn- handle-github-token-breach
[db event-emitter {:as _request :keys [headers body]}]
(let [body-str (slurp body)]
(if (valid-github-request? headers body-str)
(let [data (json/parse-string body-str true)]
- (doseq [{:keys [token url]} data]
- (when-let [{:as db-token :keys [id disabled user_id]}
- (db/find-token-by-value db token)]
- (when (not disabled)
- (db/disable-deploy-token db id))
- (event/emit event-emitter :token-breached
- {:user-id user_id
- :token-disabled? disabled
- :token-name (:name db-token)
- :commit-url url})))
- (response/status 200))
+ (response/response (mapv (partial check-token db event-emitter) data)))
(response/status 422))))
(defn routes [db event-emitter]