Code Security

The Code Security module assesses the steps taken by teams to guarantee that the project’s code and development are secure and reviewed.

Projects that are audited with CertiK undergo a rigorous security assessment are delivered an audit report which details the full scope of project risk and vulnerabilities. We publish the results of the security assessments in our Code Security module, in the Code Audit History section.

The Code Audit History section contains all the audit reports that are available for a project. The module includes the status of a project’s audit findings (acknowledged, partially acknowledged, resolved) alongside the severity of the findings. You can determine whether a project is taking actionable steps to address the results of its audit.

A “View Findings” option is available, which makes it quick to retrieve audit findings. “View Findings” presents only the code-level audit findings, allowing you to quickly reference these findings without having to parse through the full report (which is still available through the “View PDF” option).

Security risks are categorized based on their severity level and are defined in the following ways:

Critical: Critical risks are those that impact the safe functioning of a platform and must be addressed before launch. Users should not invest in any project with outstanding critical risks.

Major: Major risks can include centralization issues and logical errors. Under specific circumstances these major risks can lead to loss of funds and/or control of the project.

Medium: Medium risks may not pose a direct risk to users funds but they can affect the overall functioning of a platform.

Minor: Minor risks can be any of the above but on a smaller scale. They generally do not compromise the overall integrity of the project but they may be less efficient than other solutions.

Informational: Informational errors are often recommendations to improve the style of the code or certain operations to fall within industry best practices. They usually do not affect the overall functioning of the code.

Centralization Overview gives an at-a-glance view of a code’s centralization concerns, namely whether there are Distribution, Upgrade, Privilege or Other concerns.

Distribution: Either all or the majority of the tokens are transmitted to the contract deployer, or to one or more predetermined addresses. The activities of these addresses, such as trading, could significantly affect the value of the tokens.

Upgrade: Indicates that the admin role can update the implementation contract behind the proxy, which will change the logic/behavior of the contract.

Privilege: Indicates that privileged roles possess the authority to control functions that can impact the project's operations or the core business logic.

Other: This category encompasses other vital but uncategorized operations that a privileged role can perform. These actions may potentially influence the user and their assets.

We have recently extended our state-of-the-art Formal Verification results into Skynet project profiles. Projects that have undergone formal verification will now be identified with a “Formal Verification” tag, and there will be a section within the Code Security module that provides users with detailed information on a project’s formal verfication results.

Formal Verification is a rigorous methodology for verifying the correctness of smart contracts using mathematical algorithms and logic. This process involves analyzing source code, formalizing it into logical assertions, and then proving that these assertions hold within the given context and constraints of the code.

The formal verification section within the Code Security module contains a tooltip that explains the formal verification results:

True: Automated formal verification (symbolic model checking) proves that well-known functions in the smart contracts adhere to their expected behavior.

False: Automated formal verification (symbolic model checking) proves that well-known functions in the smart contracts do not adhere to their expected behavior.

Inapplicable: The specification of the property is too generic and does not accurately capture the intended behavior of the smart contract.

Inconclusive: The model checking engine fails to derive a conclusion regarding the property's validity.

You can also click on “Formal Verification Details” to examine detailed information about the finding, and find the complete Formal Verification results in the Audit Report.

With the growing importance of secure and reliable smart contract deployment, CertiK's Formal Verification service offers valuable assurance for crypto projects and communities looking to improve their reputation and build trust with their users. By utilizing formal verification, projects can reduce the risk of vulnerabilities and exploits, and ensure the highest level of security and trust.

To learn more about how CertiK is enhancing trust, transparency and security in the Web3 space with Formal Verification, you can refer to our collection of blog posts on formal verification at CertiK Resources.

The Audit Coverage section serves the purpose of illustrating the degree of alignment between deployed contract code and the code that has undergone an audit. In this context, 'Trending Contracts' refers to a project’s main function contract addresses, token addresses, addresses submitted by the project for audit, or other significant contract addresses provided to us for Skynet activation or monitoring. The 'Audited Code Percentage' signifies the portion of code within a project's deployed contracts that corresponds to the code that has been subjected to an audit.

The calculation of coverage involves breaking down the codebase of the project's trending contracts into distinct blocks and then assessing the coverage for each of these code blocks against our comprehensive audit database. A lower coverage percentage indicates a larger proportion of the project's code remains unaudited, potentially introducing greater risk and uncertainty into the system's operation.

Audit Freshness provides users with insights into the current relevance and timeliness of the CertiK audit. We accomplish this by displaying the number of newly deployed smart contracts and lines of code since the project's most recent audit conducted by CertiK. This information serves to indicate the extent to which the CertiK audit remains applicable and the duration that has elapsed since its completion.

The timeline, presented graphically, offers a visual representation of the volume of new lines of code introduced since the CertiK audit. It also highlights the percentage of similarity between these new lines of code and the code that underwent auditing by CertiK.

This data is vital because it allows users to gauge the extent to which the project's codebase has evolved since the audit. Understanding the correlation between new code and the previously audited code helps users assess the ongoing security and reliability of the project.

The GitHub Monitoring section offers users valuable insights into a project's GitHub account. It provides information on the account's age, its overall impact, the number of stars it has earned, and an activity heatmap depicting the account's historical activity.

Impact Indicator: This metric summarizes the overall influence of the project's GitHub account by considering various factors such as followers, stars, commits, and forks.

Activity Heatmap: This heatmap illustrates the frequency of commits made by the project's developers across all repositories within the GitHub account.

These insights are valuable because a GitHub account can tell a user how actively a project is being developed and its level of influence within the GitHub community, aiding in informed decision-making and project assessment.