{"id":1724,"date":"2025-02-12T17:15:47","date_gmt":"2025-02-12T17:15:47","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/02\/12\/how-github-uses-codeql-to-secure-github\/"},"modified":"2025-02-12T17:15:47","modified_gmt":"2025-02-12T17:15:47","slug":"how-github-uses-codeql-to-secure-github","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/02\/12\/how-github-uses-codeql-to-secure-github\/","title":{"rendered":"How GitHub uses CodeQL to secure GitHub"},"content":{"rendered":"

GitHub\u2019s Product Security Engineering team writes code and implements tools that help secure the code that powers GitHub. We use GitHub Advanced Security (GHAS) to discover, track, and remediate vulnerabilities and enforce secure coding standards at scale. One tool we rely heavily on to analyze our code at scale is CodeQL<\/a>.<\/p>\n

CodeQL is GitHub\u2019s static analysis engine that powers automated security analyses. You can use it to query code in much the same way you would query a database. It provides a much more robust way to analyze code and uncover problems than an old-fashioned text search through a codebase.<\/p>\n

The following post will detail how we use CodeQL to keep GitHub secure and how you can apply these lessons to your own organization. You will learn why and how we use:<\/p>\n

Custom query packs (and how we create and manage them).
\nCustom queries.
\nVariant analysis to uncover potentially insecure programming practices.<\/p>\n

Enabling CodeQL at scale<\/a><\/h2>\n

We employ CodeQL in a variety of ways at GitHub.<\/p>\n

Default setup<\/a><\/strong> with the default and security-extended query suites<\/a>
\nDefault setup with the default and security-extended query suites meets the needs of the vast majority of our over 10,000 repositories. With these settings, pull requests automatically get a security review from CodeQL.
\nAdvanced setup<\/a> with a custom query pack<\/strong>
\nA few repositories, like our large Ruby monolith, need extra special attention, so we use advanced setup with a query pack<\/a> containing custom queries to really tailor to our needs.
\nMulti-repository variant analysis<\/a> (MRVA)<\/strong>
\nTo conduct variant analysis and quick auditing, we use MRVA. We also write custom CodeQL queries to detect code patterns that are either specific to GitHub\u2019s codebases or patterns we want a security engineer to manually review.<\/p>\n

The specific custom Actions workflow step we use on our monolith is pretty simple. It looks like this:<\/p>\n

– name: Initialize CodeQL
\n uses: github\/codeql-action\/init@v3
\n with:
\n languages: ${{ matrix.language }}
\n config-file: .\/.github\/codeql\/${{ matrix.language }}\/codeql-config.yml<\/p>\n

Our Ruby configuration is pretty standard, but advanced setup offers a variety of configuration options using custom configuration files<\/a>. The interesting part is the packs option, which is how we enable our custom query pack as part of the CodeQL analysis. This pack contains a collection of CodeQL queries we have written for Ruby, specifically for the GitHub codebase.<\/p>\n

So, let\u2019s dive deeper into why we did that\u2014and how!<\/p>\n

Publishing our CodeQL query pack<\/a><\/h2>\n

Initially, we published CodeQL query files directly to the GitHub monolith repository, but we moved away from this approach for several reasons:<\/p>\n

It required going through the production deployment process for each new or updated query.
\nQueries not included in a query pack were not pre-compiled<\/a>, which slowed down CodeQL analysis in CI.
\nOur test suite for CodeQL queries<\/a> ran as part of the monolith\u2019s CI jobs. When a new version of the CodeQL CLI was released, it sometimes caused the query tests to fail because of changes in the query output, even when there were no changes to the code in the pull request. This often led to confusion and frustration among engineers, as the failure wasn\u2019t related to their pull request changes.<\/p>\n

By switching to publishing a query pack to GitHub Container Registry (GCR)<\/a>, we\u2019ve simplified our process and eliminated many of these pain points, making it easier to ship and maintain our CodeQL queries. So while it\u2019s possible<\/em> to deploy custom CodeQL query files directly to a repository, we recommend publishing CodeQL queries as a query pack to the GCR for easier deployment and faster iteration.<\/p>\n

Creating our query pack<\/a><\/h2>\n

When setting up our custom query pack<\/a>, we faced several considerations, particularly around managing dependencies like the ruby-all package.<\/p>\n

To ensure our custom queries remain maintainable and concise, we extend classes from the default query suite<\/a>, such as the ruby-all library. This allows us to leverage existing functionality rather than reinventing the wheel, keeping our queries concise and maintainable. However, changes to the CodeQL library API can introduce breaking changes, potentially deprecating our queries or causing errors. Since CodeQL runs as part of our CI, we wanted to minimize the chance of this happening, as this can lead to frustration and loss of trust from developers.<\/p>\n

We develop our queries against the latest version of the ruby-all package, ensuring we\u2019re always working with the most up-to-date functionality. To mitigate the risk of breaking changes affecting CI, we pin the ruby-all version when we\u2019re ready to release, locking it in the codeql-pack.lock.yml file<\/a>. This guarantees that when our queries are deployed, they will run with the specific version of ruby-all we\u2019ve tested, avoiding potential issues from unintentional updates.<\/p>\n

Here\u2019s how we manage this setup:<\/p>\n

In our qlpack.yml, we set the dependency to use the latest version of ruby-all
\nDuring development, this configuration pulls in the latest version<\/a>) of ruby-all when running codeql pack init, ensuring we\u2019re always up to date.
\n\/\/ Our custom query pack’s qlpack.yml<\/p>\n

library: false
\nname: github\/internal-ruby-codeql
\nversion: 0.2.3
\nextractor: ‘ruby’
\ndependencies:
\n codeql\/ruby-all: “*”
\ntests: ‘test’
\ndescription: “Ruby CodeQL queries used internally at GitHub”<\/p>\n

Before releasing, we lock the version in the codeql-pack.lock.yml<\/a> file, specifying the exact version to ensure stability and prevent issues in CI.
\n\/\/ Our custom query pack’s codeql-pack.lock.yml<\/p>\n

lockVersion: 1.0.0
\ndependencies:
\n …
\n codeql\/ruby-all:
\n version: 1.0.6<\/p>\n

This approach allows us to balance developing against the latest features of the ruby-all package while ensuring stability when we release.<\/p>\n

We also have a set of CodeQL unit tests<\/a> that exercise our queries against sample code snippets, which helps us quickly determine if any query will cause errors before we publish our pack. These tests are run as part of the CI process in our query pack repository, providing an early check for issues. We strongly recommend writing unit tests for your custom CodeQL queries to ensure stability and reliability.<\/p>\n

Altogether, the basic flow for releasing new CodeQL queries via our pack is as follows:<\/p>\n

Open a pull request with the new query.
\nWrite unit tests for the new query.
\nMerge the pull request.
\nIncrement the pack version in a new pull request.
\nRun codeql pack init to resolve dependencies.
\nCorrect unit tests as needed.
\nPublish the query pack to the GitHub Container Registry (GCR).
\nRepositories with the query pack in their config will start using the updated queries.<\/p>\n

We have found this flow balances our team\u2019s development experience while ensuring stability in our published query pack.<\/p>\n

Configuring our repository to use our custom query pack<\/a><\/h2>\n

We won\u2019t provide a general recommendation on configuration here, given that it ultimately depends on how your organization deploys code. We opted against locking our pack to a particular version in our CodeQL configuration file<\/a> (see above). Instead, we chose to manage our versioning by publishing the CodeQL package in GCR. This results in the GitHub monolith retrieving the latest published version of the query pack. To roll back changes, we simply have to republish the package. In one instance, we released a query that had a high number of false positives and we were able to publish a new version of the pack that removed that query in less than 15 minutes. This is faster than the time it would have taken us to merge a pull request on the monolith repository to roll back the version in the CodeQL configuration file.<\/p>\n

One of the problems we encountered with publishing the query pack in GCR was how to easily make the package available to multiple repositories within our enterprise. There are several approaches we explored.<\/p>\n

Grant access permissions for individual repositories.<\/strong> On the package management page, you can grant permissions for individual repositories to access your package. This was not a good solution for us since we have too many repositories for it to be feasible to do manually, yet there is not currently a way to configure programmatically using an API.
\nMint a personal access token for the CodeQL action runner.<\/strong> We could have minted a personal access token (PAT) that has access to read all packages for our organization and added that to the CodeQL action runner. However, this would have required managing a new token, and it seemed a bit more permissive than we wanted because it could read all<\/em> of our private packages rather than ones we explicitly allow it to have access to.
\nProvide access permissions via a linked repository.<\/strong> We ended up implementing the third solution that we explored. We link a repository to the package<\/a> and allow the package to inherit access permissions from the linked repository<\/a>. <\/p>\n

CodeQL query pack queries<\/a><\/h2>\n

We write a variety of custom queries to be used in our custom query packs. These cover GitHub-specific patterns that aren\u2019t included in the default CodeQL query pack. This allows us to tailor the analysis to patterns and preferences that are specific to our company and codebase. Some of the types of things we alert on using our custom query pack include:<\/p>\n

High-risk APIs specific to GitHub\u2019s code that can be dangerous if they receive unsanitized user input.
\nUse of specific built-in Rails methods for which we have safer, custom methods or functions.
\nRequired authorization methods not being used in our REST API endpoint definitions and GraphQL object\/mutation definitions.
\nREST API endpoints and GraphQL mutations that require engineers to define access control methods to determine which actors can access them. (Specifically, the query detects the absence of this method definition to ensure that the actors\u2019 permissions are being checked for these endpoints.)
\nUse of signed tokens so we can nudge engineers to include Product Security as a reviewer when using them.<\/p>\n

Custom queries can be used more for educational purposes rather than being blockers to shipping code. For example, we want to alert engineers when they use the ActiveRecord::decrypt<\/a> method. This method should generally not be used in production code, as it will cause an encrypted column to become decrypted. We use the recommendation severity in the query metadata<\/a> so these alerts are treated as more of an informational alert. That means this may trigger an alert in a pull request, but it won\u2019t cause the CodeQL CI job to fail. We use this lower severity level to allow engineers to assess the impact of new queries without immediate blocking. Additionally, this alert level isn\u2019t tracked through our Fundamentals program<\/a>, meaning it doesn\u2019t require immediate action, reflecting the query\u2019s maturity as we continue to refine its relevance and risk assessment.<\/p>\n

\/**
\n * @id rb\/github\/use-of-activerecord-decrypt
\n * @description Do not use the .decrypt method on AR models, this will decrypt all encrypted attributes and save
\n * them unencrypted, effectively undoing encryption and possibly making the attributes inaccessible.
\n * If you need to access the unencrypted value of any attribute, you can do so by calling my_model.attribute_name.
\n * @kind problem
\n * @severity recommendation
\n * @name Use of ActiveRecord decrypt method
\n * @tags security
\n * github-internal
\n *\/<\/p>\n

import ruby
\nimport DataFlow
\nimport codeql.ruby.DataFlow
\nimport codeql.ruby.frameworks.ActiveRecord<\/p>\n

\/** Match against .decrypt method calls where the receiver may be an ActiveRecord object *\/
\nclass ActiveRecordDecryptMethodCall extends ActiveRecordInstanceMethodCall {
\n ActiveRecordDecryptMethodCall() { this.getMethodName() = “decrypt” }
\n}<\/p>\n

from ActiveRecordDecryptMethodCall call
\nselect call,
\n “Do not use the .decrypt method on AR models, this will decrypt all encrypted attributes and save them unencrypted.<\/p>\n

Another educational query is the one mentioned above in which we detect the absence of the `control_access` method in a class that defines a REST API endpoint. If a pull request introduces a new endpoint without `control_access`, a comment will appear on the pull request saying that the `control_access` method wasn\u2019t found and it\u2019s a requirement for REST API endpoints. This will notify the reviewer of a potential issue and prompt the developer to fix it.<\/p>\n

\/**
\n * @id rb\/github\/api-control-access
\n * @name Rest API Without ‘control_access’
\n * @description All REST API endpoints must call the ‘control_access’ method, to ensure that only specified actor types are able to access the given endpoint.
\n * @kind problem
\n * @tags security
\n * github-internal
\n * @precision high
\n * @problem.severity recommendation
\n *\/<\/p>\n

import codeql.ruby.AST
\nimport codeql.ruby.DataFlow
\nimport codeql.ruby.TaintTracking
\nimport codeql.ruby.ApiGraphs<\/p>\n

\/\/ Api::App REST API endpoints should generally call the control_access method
\nprivate DataFlow::ModuleNode appModule() {
\n result = API::getTopLevelMember(“Api”).getMember(“App”).getADescendentModule() and
\n not result = protectedApiModule() and
\n not result = staffAppApiModule()
\n}<\/p>\n

\/\/ Api::Admin, Api::Staff, Api::Internal, and Api::ThirdParty REST API endpoints do not need to call the control_access method
\nprivate DataFlow::ModuleNode protectedApiModule() {
\n result =
\n API::getTopLevelMember([“Api”])
\n .getMember([“Admin”, “Staff”, “Internal”, “ThirdParty”])
\n .getADescendentModule()
\n}<\/p>\n

\/\/ Api::Staff::App REST API endpoints do not need to call the control_access method
\nprivate DataFlow::ModuleNode staffAppApiModule() {
\n result =
\n API::getTopLevelMember([“Api”]).getMember(“Staff”).getMember(“App”).getADescendentModule()
\n}<\/p>\n

private class ApiRouteWithoutControlAccess extends DataFlow::CallNode {
\n ApiRouteWithoutControlAccess() {
\n this = appModule().getAModuleLevelCall([“get”, “post”, “delete”, “patch”, “put”]) and
\n not performsAccessControl(this.getBlock())
\n }
\n}<\/p>\n

predicate performsAccessControl(DataFlow::BlockNode blocknode) {
\n accessControlCalled(blocknode.asExpr().getExpr())
\n}<\/p>\n

predicate accessControlCalled(Block block) {
\n \/\/ the method `control_access` is called somewhere inside `block`
\n block.getAStmt().getAChild*().(MethodCall).getMethodName() = “control_access”
\n}<\/p>\n

from ApiRouteWithoutControlAccess api
\nselect api.getLocation(),
\n “The control_access method was not detected in this REST API endpoint. All REST API endpoints must call this method to ensure that the endpoint is only accessible to the specified actor types.”<\/p>\n

Variant analysis<\/a><\/h2>\n

Variant analysis (VA)<\/a> refers to the process of searching for variants of security vulnerabilities. This is particularly useful when we\u2019re responding to a bug bounty submission<\/a> or a security incident. We use a combination of tools to do this, including GitHub\u2019s code search functionality, custom scripts, and CodeQL. We will often start by using code search to find patterns similar to the one that caused a particular vulnerability across numerous repositories. This is sometimes not good enough, as code search is not semantically aware, meaning that it cannot determine whether a given variable is an Active Record object or whether it is being used in an `if` expression. To answer those types of questions we turn to CodeQL.<\/p>\n

When we write CodeQL queries for variant analysis we are much less concerned about false positives, since the goal is to provide results for security engineers to analyze. The quality of the code is also not quite as important, as these queries will only be used for the duration of the VA effort. Some of the types of things we use CodeQL for during VAs are:<\/p>\n

Where are we using SHA1 hashes?
\nOne of our internal API endpoints was vulnerable to SQLi according to a recent bug bounty report. Where are we passing user input to that API endpoint?
\nThere is a problem with how some HTTP request libraries in Ruby handle the proxy setting. Can we look at places we are instantiating our HTTP request libraries with a proxy setting?<\/p>\n

One recent example involved a subtle vulnerability in Rails. We wanted to detect when the following condition was present in our code:<\/p>\n

A parameter was used to look up an Active Record object.
\nThat parameter is later reused after the Active Record object is looked up.<\/p>\n

The concern with this condition is that it could lead to an insecure direct object<\/a> reference (IDOR) vulnerability because Active Record finder methods can accept an array. If the code looks up an Active Record object in one call to determine if a given entity has access to a resource, but later uses a different element from that array to find an object reference, that can lead to an IDOR vulnerability. It would be difficult to write a query to detect all<\/em> vulnerable instances of this pattern, but we were able to write a query that found potential vulnerabilities that gave us a list of code paths to manually analyze. We ran the query against a large number of our Ruby codebases using CodeQL\u2019s MRVA.<\/p>\n

The query, which is a bit hacky and not quite production grade, is below:<\/p>\n

\/**
\n * @name wip array query
\n * @description an array is passed to an AR finder object
\n *\/<\/p>\n

import ruby
\nimport codeql.ruby.AST
\nimport codeql.ruby.ApiGraphs
\nimport codeql.ruby.frameworks.Rails
\nimport codeql.ruby.frameworks.ActiveRecord
\nimport codeql.ruby.frameworks.ActionController
\nimport codeql.ruby.DataFlow
\nimport codeql.ruby.Frameworks
\nimport codeql.ruby.TaintTracking<\/p>\n

\/\/ Gets the “final” receiver in a chain of method calls.
\n\/\/ For example, in `Foo.bar`, this would give the `Foo` access, and in
\n\/\/ `foo.bar.baz(“arg”)` it would give the `foo` variable access
\nprivate Expr getUltimateReceiver(MethodCall call) {
\n exists(Expr recv |
\n recv = call.getReceiver() and
\n (
\n result = getUltimateReceiver(recv)
\n or
\n not recv instanceof MethodCall and result = recv
\n )
\n )
\n}<\/p>\n

\/\/ Names of class methods on ActiveRecord models that may return one or more
\n\/\/ instances of that model. This also includes the `initialize` method.
\n\/\/ See https:\/\/api.rubyonrails.org\/classes\/ActiveRecord\/FinderMethods.html
\nprivate string staticFinderMethodName() {
\n exists(string baseName |
\n baseName = [“find_by”, “find_or_create_by”, “find_or_initialize_by”, “where”] and
\n result = baseName + [“”, “!”]
\n )
\n \/\/ or
\n \/\/ result = [“new”, “create”]
\n}<\/p>\n

private class ActiveRecordModelFinderCall extends ActiveRecordModelInstantiation, DataFlow::CallNode
\n{
\n private ActiveRecordModelClass cls;<\/p>\n

ActiveRecordModelFinderCall() {
\n exists(MethodCall call, Expr recv |
\n call = this.asExpr().getExpr() and
\n recv = getUltimateReceiver(call) and
\n (
\n \/\/ The receiver refers to an `ActiveRecordModelClass` by name
\n recv.(ConstantReadAccess).getAQualifiedName() = cls.getAQualifiedName()
\n or
\n \/\/ The receiver is self, and the call is within a singleton method of
\n \/\/ the `ActiveRecordModelClass`
\n recv instanceof SelfVariableAccess and
\n exists(SingletonMethod callScope |
\n callScope = call.getCfgScope() and
\n callScope = cls.getAMethod()
\n )
\n ) and
\n (
\n call.getMethodName() = staticFinderMethodName()
\n or
\n \/\/ dynamically generated finder methods
\n call.getMethodName().indexOf(“find_by_”) = 0
\n )
\n )
\n }<\/p>\n

final override ActiveRecordModelClass getClass() { result = cls }
\n}<\/p>\n

class FinderCallArgument extends DataFlow::Node {
\n private ActiveRecordModelFinderCall finderCallNode;<\/p>\n

FinderCallArgument() { this = finderCallNode.getArgument(_) }
\n}<\/p>\n

class ParamsHashReference extends DataFlow::CallNode {
\n private Rails::ParamsCall params;<\/p>\n

\/\/ TODO: only direct element references against `params` calls are considered
\n ParamsHashReference() { this.getReceiver().asExpr().getExpr() = params }<\/p>\n

string getArgString() {
\n result = this.getArgument(0).asExpr().getConstantValue().getStringlikeValue()
\n }
\n}<\/p>\n

class ArrayPassedToActiveRecordFinder extends TaintTracking::Configuration {
\n ArrayPassedToActiveRecordFinder() { this = “ArrayPassedToActiveRecordFinder” }<\/p>\n

override predicate isSource(DataFlow::Node source) { source instanceof ParamsHashReference }<\/p>\n

override predicate isSink(DataFlow::Node sink) {
\n sink instanceof FinderCallArgument
\n }<\/p>\n

string getParamsArg(DataFlow::CallNode paramsCall) {
\n result = paramsCall.getArgument(0).asExpr().getConstantValue().getStringlikeValue()
\n }<\/p>\n

\/\/ this doesn’t check for anything fancy like whether it’s reuse in a if\/else
\n \/\/ only intended for quick manual audit filtering of interesting candidates
\n \/\/ so remains fairly broad to not induce false negatives
\n predicate paramsUsedAfterLookups(DataFlow::Node source) {
\n exists(DataFlow::CallNode y | y instanceof ParamsHashReference
\n and source.getEnclosingMethod() = y.getEnclosingMethod()
\n and source != y
\n and getParamsArg(source) = getParamsArg(y)
\n \/\/ we only care if it’s used again AFTER an object lookup
\n and y.getLocation().getStartLine() > source.getLocation().getStartLine())
\n }
\n}<\/p>\n

from ArrayPassedToActiveRecordFinder config, DataFlow::Node source, DataFlow::Node sink
\nwhere config.hasFlow(source, sink) and config.paramsUsedAfterLookups(source)
\nselect source, sink.getLocation()<\/p>\n

Conclusion<\/a><\/h2>\n

CodeQL can be very useful for product security engineering teams to detect and prevent vulnerabilities at scale. We use a combination of queries that run in CI using our query pack and one-off queries run through MRVA to find potential vulnerabilities and communicate them to engineers. CodeQL isn\u2019t only useful for finding security vulnerabilities, though; it is also useful for detecting the presence or absence of security controls that are defined in code. This saves our security team time by surfacing certain security problems automatically, and saves our engineers time by detecting them earlier in the development process.<\/p>\n

Writing custom CodeQL queries<\/a><\/h2>\n

Tips for getting started<\/a><\/h3>\n

We have a large number of articles and resources for writing custom CodeQL queries. If you haven\u2019t written custom CodeQL queries before, here are some resources to help get you started:<\/p>\n

CodeQL zero to hero part 1: The fundamentals of static analysis for vulnerability research – The GitHub Blog<\/a>
\nWriting CodeQL queries<\/a>
\nUse CodeQL inside Visual Studio Code – GitHub Docs<\/a>
\nCodeQL workshops for GitHub Universe<\/a> and GitHub Satellite 2020 workshops on finding security vulnerabilities with CodeQL for Java\/JavaScript.<\/a>
\nA beginner\u2019s guide to running and managing custom CodeQL queries<\/a><\/p>\n

\n

Improve the security of your applications today by enabling CodeQL for free on your public repositories<\/a>, or try GitHub Advanced Security<\/a> for your organization.<\/p>\n<\/div>\n

Michael Recachinas, GitHub Staff Security Engineer, also contributed to this blog post.<\/em><\/p>\n

The post How GitHub uses CodeQL to secure GitHub<\/a> appeared first on The GitHub Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

GitHub\u2019s Product Security Engineering team writes code and implements tools that help secure the code that powers GitHub. We use […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[8],"tags":[],"class_list":["post-1724","post","type-post","status-publish","format-standard","hentry","category-github-engineering"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1724","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1724"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1724\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}