Admin Suridata, Author at Suridata

GitHub’s New Security Feature Made Available to Everyone

Haviv Ohayon April 6, 2023

Link copied to clipboard

Back

Back Next

GitHub, the popular Internet hosting service for software development and version control, recently announced the availability of a new service that scans for secrets in developers’ code. It offers “push protection” that blocks the accidental publication of secrets that can cause security vulnerabilities. This is a significant advance in application security.

What Is a Secret?

For GitHub users, the word “secret” has a meaning that’s distinct from the general understanding of the word. In the context of GitHub and software development, a secret is any kind of private information, such as a token, password, or private authentication used by a service provider to enable interactions between applications. The development of software frequently involves the use of secrets and the embedding of those secrets in code.

With secrets, however, comes the risk that a secret has been compromised. A developer might commit a secret to a piece of code without noticing, and by doing so, reveal it publicly — rendering the secret to be insecure. In other words, the secret is not a secret anymore. Its ability to provide unique, private connections is no longer assured. A malicious actor can use the secret as a stolen credential to mount an attack.

GitHub’s New Secret Scanning Push Protection

To mitigate the risk of embedding secrets into code and making them public, it is necessary to scan the code for the existence of the secret prior to publishing it. A developer should not use a secret in the code, especially if the code is published on the internet. That sounds simple enough, but there are two challenges in this scenario. One is correctly identifying secrets within the code, as they vary in structure from one service to another. Then, there’s the prevention. How will the developer know if he or she has secrets in their code before publishing it?

GitHub offers a solution. It has offered a built-inservice that detects secrets and alerts developers if those secrets are in their code. This feature is useful, but it only scans code that has already been published. This is not ideal, because it makes application security reactive in nature. Inevitably, some leaked secret vulnerabilities would fall between the cracks.

The new “push protection” feature, recently announced by GitHub, changes the dynamics of the situation. Push protection checks for more than one hundred types of tokens/secrets as developers push code into production. It blocks the push if it detects the presence of a secret. GitHub describes the process as scanning for what it calls “high-confidence secrets,” which has a low rate of false positives.

Push protection has two goals. First, it stops secrets from getting into code. Second, it aims to keep code secure without disrupting the developer’s experience. The alerts are built into the developer’s integrated development environment (IDE) or command line interface(CLI). The alert may contain recommendations for remediating the problem. This approach enables developers to review alerts and remove secrets from their code before they push it again. If the suggested remediation does not work, or makes sense, the developer can move ahead with the push by resolving the secret as a test case or false positive. Or he or she can flag it as a real instance but fix the issue later.

A developer can bypass the push protection.However, in that event, GitHub creates a closed security alert. If the developer flagged a secret as something to deal with later, GitHub generates an open security alert so the developer and repository admin can collaborate on remediation when they are ready to tackle the problem.

Why Push Protection is a Big Deal

It may not seem like push protection is a major advance in AppSec. It’s an incremental feature that adds to GitHub’s existing secret scanning capabilities. However, it is a significant development because it shifts code protection from being reactive to proactive. Now, instead of waiting for scans of published code to reveal the presence of secrets, developers can know about secrets before they commit and push the code into production. This makes the code more secure.

Secret scanning’s push protection is already delivering results. Since its beta release in April 2022, when it was made available to GitHub Advanced Security users, push protection has prevented 17,000 potential secret leaks. This resulted in savings of over 95,000 hours that would have been spent revoking, rotating, and remediating exposed secrets.

Conclusion

The leak of a secret exposes applications to risk. Existing reactive methods of detecting and remediating secret leaks were deficient. They were not aligned with the way developers worked, and they allowed for too much time to elapse between the discovery of a leak and its correction, if in fact such a correction ever occurred. GitHub understood that developers had to be part of the solution, empowered to deal with secrets, but in a way that would not negatively affect their productivity or overall experience. Secret scanning’s push protection is the solution. It enables proactive detection and remediation of leaked secrets.

Suridata will make sure your GitHub configuration is set to enable the new push protection feature. For more information, contact us.

Haviv Ohayon

Co-Founder & CPO

Back to list

Identifying SaaS App Risks

Haviv Ohayon February 15, 2023

Link copied to clipboard

Back

Back Next

SaaS vendors tend not to enforce strong security settings by default. Rather, they leave the details up to the client’s discretion. They do this mostly to reduce their responsibility for security. They also want to make their services less complex and easy to use, but nonetheless, the result is security risk exposure. Moreover, system administrators may inadvertently change and lower existing security settings, creating risk exposure in the process. If left untreated, inadequate security settings may allow external attackers, as well as malicious insiders, to access the SaaS. This could lead to the loss of data and other negative outcomes, such as system shutdowns, data breaches, denial of service attacks, increased expenses, and more. This article explores the issue, examining SaaS app risks and offering an approach to their mitigation.

A Growing Area of Risk Exposure

The scale of SaaS activity is one reason why risks can be such a challenge with SaaS apps. According to Vendr.com, the average organization uses 130 SaaS apps.Each app has hundreds of unique controls and settings that are subject to adjustment at will. Users have expectations for SaaS apps that may run counter to what security teams want. It can get tricky to balance security with functionality, a problem that can get more difficult to address as SaaS apps interact with one another.

The Impact of a Dynamic Environment

The dynamic nature of SaaS apps is a further factor complicating their security. SaaS apps seldom sit still. Their makers update them frequently—in some cases every day. This is one of the great things about SaaS. Users don’t have to wait for new versions. They appear automatically in the browser, usually as the result of Continuous Integration/Continuous Delivery (CI/CD) pipelines that push new code into production. The difficulty with this process is that new code often affects security settings.

Security teams may struggle to keep up, leading to a situation known as “configuration drift.” Additionally, because frequent updates to SaaS features usually result in a need to change security settings, security teams may let users change their own settings – granting excessive permissions to users so they can perform this task. The problem is that the security team may then fail to revoke those permissions at a later time. This creates risk exposure.

A Brief Note about Shared Responsibility for SaaS Security

SaaS apps work on a shared security model. This means that the vendor covers certain areas of security, such as the protection of the vendor’s physical infrastructure, networks, application security, and server operating systems. The customer is responsible for its own data security and user access controls, along with numerous security settings.This model makes sense, because the vendor cannot possibly know how to assign access privileges for the customer, to name but one example. However, the shared model can lead to confusion and omissions in security practices on the part of the customer.

Drivers of Common, but Serious SaaS App Risks

SaaS apps are exposed to risk through a variety of factors. Some of the most common include:

Misconfigurations — SaaS apps offer users and admins many configuration options, some of which can expose the user to risk. For example, Google Drive shares are available to anyone by default. This means that sensitive data could accidentally be exposed to virtually any malicious actor if this default configuration is not changed.

Deficient access management controls — Most SaaS apps allow access based on just a user name password pair. This is not secure, given the prevalence of credential stuffing attacks and comparable threats. A better practice is to implement multi-factor authentication (MFA). Risks can also arise out of misconfigured single sign on(SSO) solutions, which can accidentally allow unauthorized users to access SaaS once they have signed in elsewhere.

Third-party risks — Some SaaS apps can integrate with other, third-party SaaS apps, e.g.,using a plugin to connect a SaaS to a SaaS-based storage app, and so forth.These plugins can create risk because they may be given access permissions that are not aligned with security policies.

In attention to regulatory compliance factors — The customer is responsible for many important aspects of regulatory compliance, e.g., protecting consumer data privacy, abiding by “data sovereignty” laws, and so forth. If SaaS owners do not pay adequate attention to compliance, they can increase risks of compliance penalties and costly remediations.

Data management oversights — The SaaS vendor is not responsible for data management.It is up to the customer to define and enforce the necessary data security policies, e.g., encryption, data retention and lifecycle, and privacy controls.Without such policies, storing data in a SaaS app creates data security risk.

Lack of strong password policies — Deficient password policies can lead to excessive risk of breach, e.g., if users can choose simple passwords, and are not required to change them periodically, it becomes easier for a malicious actor to gain entry to the system, especially if MFA is not in use. It’s worth noting that not all security professionals agree that strong passwords lead to better security. Ina great example of unintended consequences, a requirement to maintain strong (i.e., difficult-to-remember) passwords can cause users to employ the same password for multiple systems, which creates risk exposure.

In attention to account statuses — When users leave their jobs, or switch to departments where they will no longer need access to a SaaS app, it is essential to switch off their access. This does not always happen, which leads to the risk of unauthorized access. The web-based nature of SaaS makes this risk particularly acute, as a former employee can access the SaaS from home and access data to which he/she has no permission to access. These are sometimes called “zombie accounts.” Sharing of accounts is a related risk, one that exposes the organization using the SaaS app to risk of unauthorized access.

Detecting and Mitigating SaaS App Risks

What can be done to mitigate such SaaS app risks? The simple answer is that the SaaS client must constantly monitor and correct the SaaS security settings to properly protect it. However, considering the number of SaaS apps at the average business, it becomes obvious that any manual processes for monitoring and correction of security settings is going to be unfeasible. There are simply too many apps and too many variables to keep track of, especially in a dynamic environment. Undetected risk exposure is a virtual certainty.

The mitigation of SaaS app risks will require automated risk detection and remediation processes. Specialized solutions, now on the market, can continually scan SaaS apps and flag potential security risks. They can then automatically address risks caused by misconfigurations, zombie accounts, and so forth. These tools can be set to conform with an organization’s unique security policies.

Conclusion

SaaS app risk is, or should be, a main area of focus for cybersecurity teams and their partners in IT operations. The potential for data breaches and system outages looms if SaaS security weaknesses are not discovered and addressed. It can be a daunting subject, though, given the number of apps in question and the range of security configurations present in each app. Solutions are available, however. They leverage automation to overcome the administrative burden of detecting and mitigating SaaS app risks.

Haviv Ohayon

Co-Founder & CPO

Back to list