5 Steps to improving your Secure Scorecard
Improve the security of your software development pipeline by following these five simple steps
The Secure Scorecard project, established by the Open Source Security Foundation (OpenSSF), sets out a series of eighteen “checks” to run against projects. These checks review open-source projects for various security controls. The checks provide a pass/fail report intended to build trust over open-source code security. If you want to build more secure code, the following five steps should help improve your Scorecard.
Step 1: Enforce the principle of least privilege
Under the principle of least privilege, an organization grants users the least amount of access they need to complete a job function. In GitHub, permissions can be either read or edit. By limiting users’ ability to change your code, you reduce the risk that someone might insert malicious code.
Private users can only provide “read” and “edit” access. Organizations have more options, which can make enforcing the principle of least privilege more difficult.
Read
Read access means that a user can read the code but can’t make any changes to it. As a best practice, permissions should be set to “read” by default. You can always grant access on a need-to-know basis later.
When you’re setting permissions, you might want to assign these users “read” only access:
- Code reviewers
- Non-coding collaborators
- Internal auditors or compliance team members
Triage
Some collaborators need to manage issues, but they don’t need “write” access. The “triage” access permissions include the ability to manage discussions and pull requests.
Some contributors who benefit from triage access include:
- Scrum masters
- IT support team members
- DevOps team members
Write
These permissions give users the ability to make changes to the project. This is the access level that most developers working on a project will need to have.
While these users can change the project, the permissions still have limitations. For example, users with “write” permissions can’t:
- Delete or restore packages
- Manage topics
- Configure pull request merges
- Push to protected branches
Maintain
Next to Admins, Maintainers have the most access within a repository. These users need to manage the repository, but you want to prevent them from having access to sensitive information or doing something destructive.
Some users that benefit from “maintain” access include:
- Project managers
- Consultants
Admin
Admins can do anything within a repository. This access level should be limited as much as possible.
Step 2: Define code review processes and metrics
Secure code review enhances security by looking for vulnerabilities in code and should be done throughout the software development lifecycle (SDLC). Fundamentally, defining your processes and your metrics helps improve your Scorecard by building security directly into the entire SDLC and creating a culture of secure coding.
What to review
Every organization discusses code review differently. However, at minimum a secure code review should include reviewing:
- Business logic and design
- Authorizations
- Cryptography
- Input validation
- Session management
- Logging and auditing
- User management and authentication
- Data validation
- Data management
- Web services
- Error handling
How to set metrics
Prior to engaging in the review, you can set SMART (Specific, Measurable, Attainable, Relevant, Timebound) metrics. For example, some SMART metrics might cover:
- How quickly the team remediates security vulnerabilities
- How many false positives are found
- How well the team prioritizes issues
- How often the same defect is found
Where to document
Whether to align with internal controls or prove governance to meet compliance requirements, you should make sure that you annotate the repository. Documenting your activities increases transparency and establishes an audit trail. It gives you a way to assign responsibility for fixing problems and track changes to ensure that the security weakness was remediated.
Step 3: Insert security at pull request
Waiting until after merge increases security risk and makes remediating vulnerabilities more time-consuming. As a best practice and way to improve your Scorecard, you should incorporate a security review at the pull request stage.
By inserting security at pull request, you can also assign responsibility directly to the developer. This reduces the burden on your application security (AppSec) team. By building scanning directly into the development process, you get better visibility into vulnerabilities in the code and its dependencies.
Another benefit of engaging in review prior to merge is that you add an additional layer of documentation. For example, compliance mandates, like the Executive Order on Improving the Nation’s Cybersecurity, look to reduce supply chain attacks by reviewing software components. The more documentation you have over security, the better off you’ll be when the auditor comes knocking.
Improving your Scorecard means focusing on preventing risky code from being merged into your default branch which is why inserting security at pull request enhances security.
Step 4: Integrate static code analysis tools into DevOps
Static Application Security Testing (SAST) integrates code analysis into the DevOps process. SAST identifies errors without running the code, meaning that it reviews the code before any security vulnerabilities are pushed to production.
Threat actors can’t reach every vulnerability. With SAST, your developers can find actual and potential vulnerabilities in code. This gives them a way to prioritize their remediation activities. If they know the riskiest vulnerabilities, they can focus on those first.
Building SAST into the workflow automates security feedback loops without requiring engineers to leave the developer environment. Security doesn’t need to slow down agile DevOps.
With the right solution, your AppSec and DevOps teams can collaborate more effectively. With ShiftLeft’s NextGen SAST, your AppSec team can build rules to manage risk that would otherwise be introduced to the main branch. This increases security and improves your Scorecard.
Step 5: Continuously monitor for vulnerabilities
None of the Scorecard checks explicitly focus on continuously monitoring for new vulnerabilities. However, best cybersecurity and secure code practices focus on continuously monitoring for new risks.
Threat actors never stop looking for new vulnerabilities to exploit, so your AppSec and DevOps teams can’t stop looking for them either. Shifting security left means recognizing that any changes to code can create a security risk, whether done by accident or with malicious intent.
Secure Scorecards Should Be The Opening, Not The Endgame
Ultimately, the whole reason that secure Scorecard ratings exist is to help build trust in open source code. Open source code is a valuable tool for developers because it allows for mind sharing and drives agile development practices. Secure Scorecards help reinforce best secure coding practices as a way to proactively improve security.
Building security directly into the SDLC shouldn’t act as a roadblock. Scorecards offer pass/fail visibility into an open-source repository’s security posture. They give you visibility into the repository owners’ practices. To secure applications, developers need to proactively review code for new security vulnerabilities and risks as part of their processes.
5 Steps to improving your Secure Scorecard was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by The ShiftLeft Team. Read the original post at: https://blog.shiftleft.io/5-steps-to-improving-your-secure-scorecard-59189fa48106?source=rss----86a4f941c7da---4
